
12.5
より複雑なシステムへのパイプラインのスケールアップ
231
で、危険だ。また、あとのステージの環境に手作業で修正を加えると、忘れられてしまうか、手作業
のステップのチェックリストに入ってオートメーションの効果を蝕んでしまうかになることが多い。
それよりも、修正はソースに対して行い、VCSにコミットするようにすべきだ。すると、その後のパ
イプラインは最初からスタートして修正を完全にテストする。変更のために使われるツールやプロセス
のためにどこかが壊れたときにも同じルールが当てはまる。ツールやプロセスを修正し、必要な変更を
コミットして、最初から最後までパイプラインを実行するのである。パイプラインが十分高速に作られ
ていれば、これが苦痛になることはないはずだ。
12.4.3
プラクティス:失敗が起きたらラインを止めよ
あるステージが失敗したら、そのステージよりも上流でコンポーネントに変更を加えている人は、全
員コミットを中断しなければならない。そうでなければ、壊れた環境に新しい変更が蓄積し、問題を起
こした部分を解きほぐすことが難しくなる。
そういうわけで、失敗が起きたらラインを止めなければならない。誰が修復に当たっているかを把
握し、必要な場合には、彼らをサポートしよう。すぐにフィックスできないようであれば、その変更を
ロールバックして、パイプラインが緑ランプに戻るようにする。
緊 急 フィック ス
緊急フィックスでも、かならずパイプラインを使わなければならない。パイプラインに十分
なスピードや信頼性がない場合には、十分になるまで改 ...