Mirosław Jedynak - .NET blog: 6 steps to successful Continuous Integration
「Continuous Integrationを成功させる６つの方法」って感じか？
＃hudsonカテゴリだけど，普通のCIネタ。なんか世の中的にも最近CIネタ多くない？
それぞれの方法について，初期コストと維持コストの対比が提示されているところが印象的。感覚的だけど，このグラフは同意できる。
Mirosław Jedynak - .NET blog: 6 steps to successful Continuous Integration
Establish vs. maintain cost for Continuous Integration
で，６つの方法とは，こんなやつ。
1. Use source code repository
「SCM使えって当たり前だろ」と思いつつも，未だにOSのファイル共有だけってのもあるからなぁ。現実は小説より奇なりダ。
これは鉄板。SCM使う発想がない時点で，そのプロジェクトは終わってる。
2. Introduce check-in policy
チェックインポリシーねぇ。参加者全員に周知させる必要があるから，なかなか実践しずらいよね。コミットログ書かないヤツとか，なんでもまとめて一括コミットするヤツとか，何度言っても守らない人は守らない。:-(
基本的にマメじゃないとね。まあライブラリアンがマメだったら何とかなるレベルのルールかな。
3. Automate build
1.とこれは鉄板だろう。つうかAntとかMavenとか気取らなくていいから，まずやっとけ（もうバッチファイルでいい）。ただ，対話型にしないようにね。
あたしは，VBAからjavac叩くマクロを組んで，Excelに実行ボタン貼ってるビルドシステムを見た事があるっ。
4. Create auto-deployable test environment
この発想はなかった。次から実践してみよう。
5. Use code quality analysis
品質検査ねぇ。いやいやツールそのものを批判する気はないが，運用がまずくてうまく回ってないケースをよく見るんで，あまり乗り気じゃない。
正直，FindBugsやCheckStyleなどのインスペクションはプログラマ個々人がたしなみとしてやるべきだと思ってる。なんでプロジェクト全体のサマリ出しても自分がやるって意識が薄くなるんじゃないかなぁって。
おっと，ちょっと個人的な話になり過ぎたな。そんでもインスペクションツールが揃っている（しかもOSSで）ってのはメジャー言語の特権なので使わない手は無いぞ。
6. Use unit test
うまく行ったときは効果絶大なんだけど，度重なる仕様変更などでテスト資産が不良債権化しないように維持するのが大変なので，バランス取りがとっても難しい。
これもまた，ある程度のマメさがないと良いテストコードを組んでもらえない。
なによりこの６項目，それなりに感ずることができるチーム（個人じゃダメよ）だったら，よほどの事が無い限り困る事は無いと思うぞ。
＃もうCIがどうこうって話じゃないね。:-P
