CIのアンチパターン

CI

万人のためのオートメーション: 継続的インテグレーションのアンチパターンという記事をyamashiroさんのブログで見た。
アンチパターンを以下に。

  • 頻繁にチェックインを行わないため、インテグレーションに遅れが生じる
  • ビルドに失敗しているため、チームが他の作業に進めない
  • フィードバックが少ないため、対応することができない
  • やみくもにフィードバックが送られてくることから、人々がメッセージを無視するようになる
  • 遅いマシンを使用していることが原因で、フィードバックに遅れが出る
  • 肥大化したビルドに依存しているため、フィードバックに時間がかかる

CIの思想というか、考えとしてはyamashiroさんが言ってるように、

ビルド、テストをチェックインのタイミングで継続的に行うことで、エラーが起こった箇所をすばやく特定し、修正できる

ということには大いに賛成。
自分としてはそれに付け加え、未来における手戻りコストを現時点のコストにし軽減する、というものだと考えている。
ここで、アンチパターンに陥るのは技術者の力不足というよりも、政治的な理由でどうにもならないことのほうが大きいと思う。
プロジェクトメンバ間の意思の統一ができてなかったり、プロジェクトの構成を変えれない立場であったり、早いサーバマシンを調達できなかったり、と。
そういう意味で、CIって敷居が高いのかもね。