翻訳第３回です。このセクションは長いので今回は途中まで。
週末はちょいと旅行に出かけるので、次の更新はおそらく来週になります。
The Catch
難題
Let’s imagine that all database changes need to be checked into an isolated directory in source-control; we’re not savages after all. However, since they don’t really “build” a database from the source files, that directory will be ignored by their continuous-integration server. This in turn breaks the unit tests that are pointing to the integration database server, so Jimmy then needs to run those scripts manually in the integration environment.
データベースへの全ての変更がソース管理とは無関係のディレクトリへチェックインされている状況を想像してみよう。それほどいい加減な扱いはしないだろうが、ファイルからデータベースを本当に「ビルド」することはできない。継続的インテグレーションサーバーはそのディレクトリへはアクセスしない。こうして統合テスト用データベースを使用するユニットテストはパスしなくなる。だからジミーは統合テスト環境に対して手作業でデータベース用のスクリプトを実行しなければならない。
In this process, Jimmy sees other database scripts that were checked in recently in the same source-control directory, but he has no way to know which scripts have already been applied to the integration server. For the briefest moment, Jimmy considers applying those scripts as well, just to make sure that the integration server is fully up-to-date, but then he realizes that he can’t be sure which scripts have already been run without manually comparing the schema and scripts to see which have been applied, and this would make Jimmy the de facto owner for any issue that arise because of it. With his own tasks and deadlines to worry about, Jimmy doesn’t have the time or patience for this silliness, so he just deploys his scripts, forgets about the others, and hopes for the best.
ジミーは同じソース管理用ディレクトリに他のデータベーススクリプトが最近チェックインされていないことに気づいた。しかしこのようなプロセスではどのスクリプトが統合テスト用サーバーに展開されたのか知る術がない。統合テスト環境を最新版にするために、ジミーは一瞬これらのスクリプトもサーバーへ展開しようと考える。しかしジミーは手作業でスキーマとスクリプトを比較しない限り、どのスクリプトが展開済みなのか確信を持つことができない。この結果、ジミーは暗黙の了解で問題発生時の第一担当者になってしまう。自分のタスクや締め切りを抱えていたとしても、ジミーはその仕事をする時間がない。彼は他のことを忘れて一生懸命スクリプトをデプロイし続けることになる。
This is something that can silently kill software quality. A motivated developer just tried to make things a little better, but the process was so frustratingly inadequate that it was impractical for him to do so. Software companies depend on their developers taking the initiative to improve things, and when they are discouraged from doing so, either by person or by process, the company will slowly slide backwards into mediocrity, and it will drag every developer’s morale with them.
これがソフトウェア品質が密かに低下する原因である。熱意のある開発者なら状況を少しでも改善しようとする。しかしプロセスが全くもってダメダメなので彼らにはどうすることもできない。ソフトウェア会社は自ら進んで改善しようとする開発者に依存している。人の問題にしろ、プロセスの問題にしろ、うまくいかないことがあると、会社は徐々に凡庸さを良しとし始める。そうして開発者のやる気まで削いでしまうのだ。
So now when Jimmy makes the changes to the integration server database, that then breaks things for some other developers that have been using that server for their development. Those developers now need to stop and download the latest code changes to get back in sync, cursing Jimmy’s name the whole way.
さて、ジミーが統合テスト用データベースに変更を加えると、そのサーバーを開発で使っていた他の開発者に問題が発生する。被害を被った開発者たちは作業を止め、コードを同期するために最後のコード変更をダウンロードしなければならない。こうしてジミーの評判は下がっていく。
