give IT a try


When Database Source Control Goes Bad 翻訳 Part9

The End… ?


And in the end, it is all about productivity. Much like every other aspect of development, your approach should not be dictated by what you enjoy, or your religious language preferences, or office politics, or any of that other junk that just serves as a distraction. In the end, the only really important criteria is whether your approach is going to help you and your team get more done in less time.


So please work to improve your database source-control. Think of the children. At least, the ones that will have to grow up and deal with your legacy crap. And yes, no matter how good of a job you do, they will vilify you anyway.


But in your quest to improve, keep an objective eye on your progress. If you come up with a system that introduces a little bit of overhead but greatly reduces integration issues and deployment-time debugging, great. But however if your process introduces more overhead and doesn’t actually reduce integration issues (and this will be the case most of the time), you have to be grownup enough to admit it and change what you are doing. Experienced developers tend get stuck in a rut of what they are used to doing, and refuse to change because it inevitably implies that they were wrong, and the company and their career suffers from the resulting mediocrity. One of the true tests of a developer’s wisdom is how readily they will objectively admit, to themselves and everyone else, that their grand idea completely sucked and should be thrown out. So to wrap up, here are the key things to remember: keep it scripted, keep it source-controlled, keep it trackable, and keep it local. Draw big fat lines between your environments, and handle promotion of database scripts even more thoroughly than your application code. Ensure that you can recreate any database anywhere, anytime, and use that create separate databases for every single environment, especially local development environments. Be aware of the politics and work around them the best you can, but don’t get pulled into them yourself. Clearly define your ground rules for how developers are going to merge your changes together. Lean heavily on your build server to enforce as much of this as possible, because a process that is enforced manually is a process that will never be followed.


There are a million ways to approach this, some of them good, most of them not, but only you can determine what will fit your organization. So no matter what, keep working at it constantly. Like the rest of your code base and the rest of your development processes, you are either constantly working to improve it, or you are letting it get worse. Start small, take on responsibility yourself, make some minor improvements, lead by example, show people how much easier things can be. Good luck

こうしたアプローチは星の数ほどある。良いアプローチもいくつかあるが、大半はそうではない。しかし、自分の組織に何が合うのかを決定できるのはあなただけだ。それが何であれ、それを常に守って作業しなければならない。コードベースや開発プロセスと同様、あなたは常にそのアプローチを改善しているか、ほったらかしにして悪化させているかのどちらかだ。小さいことから始めよう。責任を引き受けよう。小さな改善を起こそう。手本を示そう。これまでの問題がどれだけ簡単になるかみんなに教えよう。Good luck。