Isolating your development database
開発用データベースを隔離する
Imagine that you working on a project that involves several layers of DLLs communicating with each other. Because you are in active development, you and your team are constantly making changes that affect the interfaces between those DLLs. The result in is that you continually need to check in your changes in a whole batches; you can’t just check in a few files here and there because you will be breaking the interfaces for anyone else working in that code.
互いに通信し合うDLLのレイヤーが関係するプロジェクトにあなたが参加していることを想像してみよう。あなたは開発作業中なので、あなたやあなたのチームはDLL間のインターフェースに影響を与えるような変更を継続的に行っている。この結果、あなたはすべてのバッチにおいて自分の変更を継続的にチェックしなければならない。他のメンバーが開発しているインタフェースを破壊するかもしれないので、あなたはいくつかのファイルを少々チェックするだけで終わるわけにはいかないのだ。
The same rules must apply to the databases as well, for all of the same reasons. At any given point in time, anyone should be able to pull the code that is in source-control, build it, and run it. However, if I’m making a series of changes to my local code and the shared development database, my crazy C# changes are isolated on my local machine, but coworkers are getting my database changes as they happen, so their systems will stop working all of the sudden, and they won’t even know why, or worse yet they will know exactly why and I’ll be the guy “who busted everything up.”
これと全く同じ理由で、全く同じルールをデータベースにも適用しなければならない。いつの時点であっても、誰もがソース管理からコードを取り出し、ビルドし、実行できるようにすべきである。しかし、もし私がローカル環境のコードと共有データベースサーバーに変更を加えると、私のクレイジーなC#の変更はローカルマシンに隔離されていたとしても、同僚たちは私のデータベース変更の影響を受ける。そしてシステムは突然停止する。彼らはなぜ停止してしまったのか分からない。さらに悪い状況は、彼らがなぜ停止したのかを突き止め、私が「事件の張本人」になってしまうことだ。
Better yet, after a few days of wasting time on a bad design, I give up on it, and with one or two clicks I can undo all of my code changes and roll back to the main development code stream. However, there is no one-click rollback to the database schema, and so now those changes need to be manually backed out. Hopefully I kept a good list of the changes so I can do this without missing anything, but we all know that a few things will get missed, and now the development database becomes even more of a mutant branch of the true database schema, full of changes that nobody remember or owns, and it is all going to blow up and make us all look like fools when we are rushing to deploy it into QA next month.
ダメな設計に時間を数日費やした後にそれを諦めたとしても、良いことに私は一度か二度クリックするだけでコードの変更を取り消し、ロールバックすることができる。しかし、データベーススキーマの変更に関してはワンクリックでロールバックする方法はないため、加えた変更は手作業で戻さなくてはならない。もし私が変更履歴をきちんと残していれば、私は問題なく変更を取り消すことができる。しかし少しでもモレがあると、開発用データベースは本来のデータベーススキーマの突然変異体になってしまう。誰一人としてすべての変更点を覚えていないのだ。こうした事態はすべてを台無しにしてしまい、翌月QA環境に急いでデプロイしたときに我々は全員唖然呆然と立ち尽くすことになる。
This leads to one of the core rules of source code management: If you are manually keeping track of any changes, you are doing it wrong, period.
上記のような問題からソースコード管理に関する重要な法則が導かれる ー 「もし手作業で変更点を管理しているなら、すでにどこかで間違っている」以上。
