続・CIのアンチパターン

CI

万人のためのオートメーション: 継続的インテグレーションのアンチパターンから。
前回の記事はおおまかなことしかはなしていないので、今回はアンチパターン一つ一つについて書いてみる。

  • 頻繁にチェックインを行わないため、インテグレーションに遅れが生じる
    • 低頻度のチェックイン

　 　　　　これはコミットするときに複数の機能をまとめてコミットするケースを指す。
　 　　　　改善するには、コミットする単位をアトミック*1にする。
　 　　　　そうすることで、ビルドエラーやテストエラーが起きたときに、どの場所かを特定しやすくなる。
　 　　　　また、コミット漏れも防ぎやすくなる。

  • ビルドに失敗しているため、チームが他の作業に進めない
    • ビルドの失敗

　 　　　　ビルドに失敗することはダメなことではなく、早期に問題を発見できるためその責任を言及してはいけない。
　 　　　　大事なことは、ビルドの失敗の修正で、これを放置するとあとで手痛い状況になる。
　 　　　　ちょっと話がずれるが、MicroSoftがVisualStudio2008を開発する上で、バグの数が40から50を越えたあたりで開発を止めてバグの修正をしたという話がある。
　 　　　　その結果、以前の2005に比べバグの総数が一桁減った。
　 　　　　http://www.atmarkit.co.jp/news/200711/20/vs.html

  • フィードバックが少ないため、対応することができない
    • 最小限のフィードバック

　 　　　　頻繁にビルド状態の通知がうっとおしくなって、通知する頻度を下げるケースを指す。
　 　　　　メールだと確かにそう思うかもしれないけど、例えばビルドエラーだけを通知するということにすればいいだけだと思う。
　 　　　　そもそも、ビルドエラーが頻繁に送られてくる状況は異常事態であり、早急に改善しないといけない。
　 　　　　また、メールだけでなくRSSやIMを使うという手段もあるため、メンバーの好みに合わせて通知手段を選ぶ必要がある。

  • やみくもにフィードバックが送られてくることから、人々がメッセージを無視するようになる
    • 大量のフィードバック

　 　　　　上のケースの真逆で、あんまり多くても人間に処理できなくなる。
　 　　　　よって、メンバーがプロジェクトの携わってる範囲内のものだけを通知するようにしておけばいい。

  • 遅いマシンを使用していることが原因で、フィードバックに遅れが出る
    • 処理速度の遅いマシン

　 　　　　これは速いマシン、もしくは複数マシンを用意すべきである。
　 　　　　実際、マシンよりも人間を使うほうが高くつく。
　 　　　　有能であればあるほど、長い時間かかるほど、高くつく。

  • 肥大化したビルドに依存しているため、フィードバックに時間がかかる
    • 肥大化したビルド

　 　　　　巨大なプロジェクトの場合で、一回ビルドがはじまると、例えば数十分以上かかってしまうケース。
　 　　　　ビルドする単位をできるだけ細かくすることで逐次的に結果を得られ、フィードバッグを得られやすくなる。
　 　　　　また、エラー箇所の特定もしやすくなるため、分けられるなら分けたほうがいい。



それと、記事の最後のほうに言及されているアンチパターンも書いてみる。

  • 継続的イグノランス。ビルドが最小限のプロセスで構成されることから、ビルドは常に成功した状態になってしまいます。

　 　　　　常に成功するようにしているため、やっても意味無いということらしい。
　 　　　　テストの充実をしないといけない、ということでしょう。

  • 使用しているマシンでしか有効でないビルド。欠陥が発生してからそれを修正するまでの時間が長引く場合があります。

　 　　　　これはプロジェクトが環境依存になっているケース。
　 　　　　ビルドマシンが壊れた場合やスケールアウトする場合にも痛い目をみる。
　 　　　　全部が全部できなくても、極力こういう部分をなくす努力は必要だ。

  • ボトルネックのコミット。ビルドに失敗する原因となりがちで、チームのメンバーがなかなか家に帰れなくなります。

　 　　　　ビルドに失敗し続けている状況というのは異常事態なので、それを取り除くことを最優先するしかない。

  • 断続的なビルドの実行。迅速なフィードバックを妨げます。

　 　　　　これは定期実行できるようにすればいいだけだと思う。
　 　　　　マシンの性能面で無理なら、追加やリプレースする必要がある。

*1:これ以上分割不可能な単位