CI のアンチパターン

Continuous Integration のアンチパターンというのを見つけた。
『Automation for the people: Continuous Integration anti-patterns』

Infrequent check-ins
現象：チェックインの頻度が少ないせいでIntegration が遅れる。Integration が遅れてリアルタイム性が低下すると、後の是正措置の手間が大きくなり、CI の恩恵が減ってくる。
対策：ちょっとずつ細かくチェックインする。少なくとも1日一回、できれば何度も。

Broken builds
現象：ビルド失敗が長時間放置される。その間、他のメンバが更新・チェックアウトできない状態も続く。
対策：コミット前にローカルでビルドする。ビルドの前に一度 update することも忘れずに行う。

Minimal feedback
現象：ビルド失敗通知を設定していなかったり、あるいは通知が地味過ぎて誰も気づかない。
対策：適切なフィードバック手法を使って、ビルド失敗が担当者に確実に認識されるように工夫する。

Spam feedback
現象：Minimal feedback とは逆に、ビルド結果のフィードバックが多すぎて、誰も注意を払わなくなる。
対策：メンバーのロールに応じて通知条件を設定して、無関係な人にスパムメール的な通知が送られないようにする。

Slow machine
現象：マシン性能が低すぎてビルドに時間がかかりフィードバックが遅れる
対策：使えるブツを調達する

Bloated build
現象：一つのビルドプロセスに静的解析やらパフォーマンステストやら、何もかも詰め込みすぎている。そのため時間がかかり過ぎてリアルタイム性が低下している。
対策：ビルドプロセスを段階的に構成し、総ビルド時間の20%でエラーの80%を補足するようなビルドを第一段階に持ってくる。