CruiseControl.rbはポーリング型

CIツールは、SubversionなどのSCMのリポジトリにソースがチェックインされたタイミングで、ビルドしてテスト…というのが「継続的結合」たる動作なわけですが…
これには2つのやり方があって…

  1. チェックイン時、SCM側のトリガーでCIをキックしてビルドスタート
  2. CI側から定期的にSCMリポジトリをポーリングして変更をキャッチしたらビルドスタート

1.の方法はSunの川口耕介さんが作ったHudson(http://hudson.dev.java.net/)があります。TracLightningに同梱されています。
(最近までsunで作られたものなので、Java専用だと思い込んでいたのは私です…..RubyでＨｕｄsｏｎの記事は別エントリーで…)
CruiseControl.rbは2.のポーリング型になります。
少数のプロジェクトをCIするなら、それほどシステムへの負荷は高くないですが、多数のまた大規模なプロジェクトを監視して…となると負荷が高そうです。
CIサーバーの比較表が、CruiseControlの会社にありました。
http://confluence.public.thoughtworks.org/display/CC/CI%20Feature%20Matrix
Hudsonと比較すると、CruiseControl.rbは純粋な(狭義の??)CIに徹している感じで、多機能ではないですがサーバー自体は軽い印象です。カスタマイズはプロジェクトごとに持っている”cruise_config.rb”というファイルに記述していきます。
設定ファイルっぽいけど、実はRubyのソースなので柔軟なカスタマイズが可能な模様。
HudsonはWebインターフェースが充実していて、設定はWebから全部できます。
また多彩なプラグインも公開されていて、なんとrakeプラグイン、ruby metricsプラグインもあってRubyの開発でもOK!!! notificationとしても標準でE-MAILを持っていますし、各種IMに対応している模様。
表示もリッチで、プラグインによる拡張性もありありって感じですね。
もっと小難しいのではないかと思って敬遠していて損した気分です。
というわけで、今後はCruiseControl.rbはちょっとお休みして、HudsonでRubyしていく状況をポストしていきます。
(CruiseControl.rbをあきらめたわけでは…でわ…でわ…..)

コメント