継続的インテグレーションのアンチパターン
IBM developerWorks:万人のためのオートメーション: 継続的インテグレーションのアンチパターン
継続的インテグレーション（CI）について、アンチパターンが紹介されています。
CIは、品質向上のためのひとつの施策有効だと考えていますが、実プロジェクトで導入しているケースはさほど多くないように思います。
CIの導入を成功させるにあたり、以下のアンチパターン、およびその対処策を知っておくことは重要だと言えるでしょう。
- 第 1 回
- 頻繁にチェックインを行わないため、インテグレーションに遅れが生じる
- ビルドに失敗しているため、チームが他の作業に進めない
- フィードバックが少ないため、対応することができない
- やみくもにフィードバックが送られてくることから、人々がメッセージを無視するようになる
- 遅いマシンを使用していることが原因で、フィードバックに遅れが出る
- 肥大化したビルドに依存しているため、フィードバックに時間がかかる
- 第 2 回
- その日の終わりまで変更をコミットしないため、ボトルネックのコミットとなる。これによって大抵はビルドに失敗し、開発者を苛立たせる結果となる
- 最小限の自動プロセスで構成されていることが理由でビルドが常に成功する。そのため継続的イグノランスという結果に至り、インテグレーションの問題がなかなか発覚しない
- コードが変更されるたびにソフトウェアをビルドするのではなく定期ビルドを優先することから、ビルドの修正が遅れる
- 自分のマシンではコードが有効に機能すると信じ込んでしまうため、後でコードを他の環境で実行するまで問題が見つからない
- 古いビルド成果物を取り除かなかったため、残骸が残ったままの環境となり、エラーの誤検出や検出漏れが発生する
