このセクションは長いので今回は途中まで。週末はちょいと旅行に出かけるので、次の更新はおそらく来週になります。environment.データベースへの全ての変更がソース管理とは無関係のディレクトリへチェックインされている状況を想像してみよう。それほどいい加減な扱いはしないだろうが、ファイルからデータベースを本当に「ビルド」することはできない。継続的インテグレーションサーバーはそのディレクトリへはアクセスしない。して統合テスト用データベースを使用するユニットテストはパスしなくなる。ジミーは統合テスト環境に対して手作業でデータベース用のスクリプトを実行しなければならない。best.ジミーは同じソース管理用ディレクトリに他のデータベーススクリプトが最近チェックインされていないことに気づいた。このようなプロセスではどのスクリプトが統合テスト用サーバーに展開されたのか知る術がない。統合テスト環境を最新版にするために、ジミーは一瞬これらのスクリプトもサーバーへ展開しようと考える。ジミーは手作業でスキーマとスクリプトを比較しない限り、どのスクリプトが展開済みなのか確信を持つことができない。この結果、ジミーは暗黙の了解で問題発生時の第一担当者になってしまう。自分のタスクや締め切りを抱えていたとしても、ジミーはその仕事をする時間がない。彼は他のことを忘れて一生懸命スクリプトをデプロイし続けることになる。them.これがソフトウェア品質が密かに低下する原因である。熱意のある開発者なら状況を少しでも改善しようとする。プロセスが全くもってダメダメなので彼らにはどうすることもできない。ソフトウェア会社は自ら進んで改善しようとする開発者に依存している。人の問題にしろ、プロセスの問題にしろ、うまくいかないことがあると、会社は徐々に凡庸さを良しとし始める。して開発者のやる気まで削いでしまうのだ。way.さて、ジミーが統合テスト用データベースに変更を加えると、そのサーバーを開発で使っていた他の開発者に問題が発生する。被害を被った開発者たちは作業を止め、コードを同期するために最後のコード変更をダウンロードしなければならない。してジミーの評判は下がっていく。はてなブログPro株式会社ソニックガーデンで働くRubyプログラマ。2017年11月に「プロを目指す人のためのRuby入門」を出版。blog)はてなブログをはじめよう!JunichiItoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。