Hudsonを使ってる感想を聞いてみて
ダイチャン(id:daisuke_m)にSearsarConの2次会でJiemamyで使ってるHudsonを使ってる感想を聞きました。
ダイチャン曰く、JiemamyのJobの状態が黄色だと危機感がないので、赤くできないか？と言われました。
そして、テストケースだけ実装したテストクラスはスキップできないか、ということも言われました、たぶん。
これについては、ちょっと記憶が定かじゃないですが＾＾；
そして、あるJobが失敗した場合、それにチェーンされているJobがビルドされなくて困る、ということも言われたと思います。
それで最初のことですが、そもそも、Jobの状態を表す色は青=成功、黄=ビルドが不安定、赤=ビルドの失敗orテストの失敗など、というような区分になっています*1。
信号の色なので黄色は大丈夫だろうと思ってしまう人がいますが、CI的にはできるだけ青い状態にし、黄色い状態にでもしては駄目だという認識です。
それで不安定な状態すらも赤にしてしまうと、失敗したビルドと区別しにくくなるので、個人的にはちょっと、と思うところです。
色にちなんだ話はHudsonのメーリングリストでたびたびあがってくる話題で、やれ青じゃなくて緑にしろ*2、とかありますので難しい問題です。
次に二つ目のことですが、これはビルドツール側で対応することかなと思います。
Mavenだとコマンドの引数にスキップするテストクラスをしていすればスキップできたはずなので、そういう機能を使えばいけると思ってます。
しかし、そもそもローカルでビルドしてテストが失敗する状態のものをリポジトリにコミットするのは、CIとしては勧められたものではないです。
一方、OSSプロジェクトでそれを厳格に適用しにくい、ということも理解できます。
なので、テストケースだけ先にコミットする場合では、先ほど述べたようなスキップする用の何かしらのことをする必要がありますね。
余談ですが、チェーンされた一連のJob郡のなかで、明示的な指定されたJobのスキップ機能はあってもいいかもしれませんね。
次に三つ目のことですが、これはそもそも後ろのJobが前のJobに依存していることを考えると、ビルドがそのまま行われるとリソースを無駄に消費してしまうことになりますし、そもそもビルドツールが処理を打ち切ってしまうことも考えられます。
一般的には、上手くJobのチェーンの組み方を変えるぐらいしか対策はないかと思います。
「Maven2プロジェクトのビルド」の場合はマルチモジュールのところをHudsonが解釈するため、こういう状況のための対策はする必要があると思います。
総じて、実際のプロジェクトにCIを厳格に導入するにはいろいろと難しい、というところでしょうか。
