Hudsonを使ったアジャイルな開発入門

第2回 Hudson事始め

この記事を読むのに必要な時間:およそ 5 分

ソースコード管理システムの設定

Hudsonは標準でCVSとSubversionをサポートしています。これ以外のソースコード管理システムを使う際には,個別のプラグインをインストールしてください。設定は単純だと思いますが(下図参照),特筆すべき点がいくつかあります。Hudsonは外部のCVS実行可能ファイルを呼び出してCVSを操作するので,このCVSプログラムがリポジトリアクセスに必要な認証情報を持っている必要があります。通常はこの情報は~/.cvspassに格納されていますが,CVSNTなどWindows用のCVSの一部にはレジストリなど非標準の位置を利用するものがあるので注意が必要です。また,後に HudsonをTomcatなどのコンテナ上で走らせる場合,Hudsonを実行しているユーザーが変化することになるので,正しいユーザーで「cvs login」を実行して認証情報をセットしてください。匿名アクセスが可能なリポジトリの場合にはこのような問題はなく,またSubversionについてはHudson上から認証情報を設定できるので,このような繁雑な問題はありません。

画像

Hudson をcronの置き換えとしてソフトウェアのビルド以外の自動化用途に使う場合,例えば何かのバックアップをとったりとか,定期的なバッチジョブの実行などですが,ソースコード管理を使う必要がないので「なし」を選択しましょう。また,特殊なチェックアウトが必要な場合(例えば複数の種類のリポジトリの混在など)やお使いのソースコード管理システム向けのプラグインがない場合も,ここで「なし」を選択しておいて,シェルスクリプトを使ってチェックアウトをする事になります。

ビルドトリガの設定

ソースコードの次は,いつビルドが行われるのかに関わる「ビルド・トリガ」の設定をします。CIの主眼はソースコードの変更をできるだけ早くビルド・テストすることですから,トリガのタイミングとしては変更がリポジトリにコミットされたらビルドを行うのが普通で,これには大きくわけて2つの方法があります。

1つ目は,ソースコード管理システムをHudsonが定期的にポーリングする方式です。この方法は,ソースコード管理システム側に変更が必要ないので設定が単純だというメリットがありますが,ポーリングの間隔を頻繁にしすぎるとソースコード管理システムによっては大きな負荷がかかり,とはいえ間隔を伸ばしすぎるとコミットをしてからビルドが行われるまでに大きなタイムラグが発生するという問題を生じます。CVSでは,その性質上ポーリングにワークスペースの規模に比例する処理時間がかかるので,頻繁なポーリングは全く現実的ではありません。Subversionでは,ポーリングはワークスペースの規模によらず一定時間で高速に行えるので,ポーリングは現実味のある選択肢です。

いずれにせよ,ポーリングでは,どのように設定してもコミット直後にビルドを開始することができません。ポーリングは最短でも1分間隔なので,全力でポーリングしても平均30秒の待ち時間が発生しますし,ポーリング間隔を現実的に設定すると待ち時間が30分,1時間となるのは普通です。

この問題を解決するには,変更がコミットされた時に,ソースコード管理システム側からHudsonに通知するという方法を使います。具体的な方法はそれぞれに違いますが,例えばCVSではCVSROOT/loginfoを使い,Subversionではリポジトリ上のhooks/post-commitを使うとこういったことができます。これらのスクリプトからリポジトリへの変更を特定し,そこからさらにビルドするべきHudsonのジョブを決定したら,⁠ビルドの実行」がクリックされた効果をシミュレートするために次のようにすればOKです。お使いの環境での実際のURLを取得するには,ブラウザで「ビルド実行」リンクのアドレスをコピーすればよいでしょう。

wget -O /dev/null "http://localhost:8080/job/foobar/build?delay=3sec"

CVS の場合,コミットが複数のディレクトリに跨るとあたかも複数のコミットが起こったかのように連続してloginfoが実行されるので,先の例に示したようにdelayパラメータを使って,Hudsonがビルドを開始するまでに数秒の待ち時間を入れましょう。これによって,変更が全て一括してビルドされるようになります。

ソースコードリポジトリの管理がチームの外で行われていて(例えばリポジトリを SourceForgeやjava.netにホストしている場合など)コミットフックを変更することができない場合,コミット通知メールをHudsonが受け取ったタイミングでビルドを行う,というようにすることもできます。実際の方法は使っているメールサーバによって異なりますが,例えばeximならば ~/.forwardを使って,こういった処理を行うことができます。Hudsonを専用ユーザーIDで運用する場合などには,このユーザーの ~/.forwardファイルを利用すればよいでしょう。この方法は初期のセットアップが大変ですが,一度やってしまうと沢山のプロジェクトでほぼ追加コストなしに利用できるので,大規模な環境では向いています。筆者の職場では実際qmailを使って「hudson- xyz@kohsuke.sfbay.sun.com」宛にメールが届くとプロジェクトxyzがビルドされる,という風に運用しています。

このように,ソースコード管理システム側から変更をプッシュする方式は設定が環境依存で繁雑ですが,Hudsonの有用性はビルドの結果を如何に素早く報告できるかで大きく変わってきます。可能であればぜひこのような設定をしたいところです。

定期的に実行

「定期的に実行」はビルドトリガの一つで,ちょうどcronのように予め指定された時刻になると自動でビルドを行う仕組みです。

CIシステムがはやる以前は,プロジェクトの自動ビルドというと,⁠ナイトリービルド」などの定時実行が主流でした。このため,Hudsonを新規に導入するユーザーは,つい無意識にこの「定期的に実行」を選んでしまいがちです。しかし,Hudsonを導入するメリットの一つは極力早くビルド結果をフィードバックすることにあるので,ソースコードの変更のタイミングとは無関係にビルドをするというこの設定はできるだけ避けるべきです。特に,一日一回しかビルドをしないという貧乏臭い発想は捨てて,コンピュータの代金の元をとってやるという位の気合でできるだけ頻繁にビルドしてみてください。

なお,CI以外の自動化用途にHudsonを使う場合などで,定期的な実行が有用である場合があるのはもちろんの事です。また,cronの文法にはモダンなものを採用しているので,⁠*/15」で15分おきに,といった便利な記法が色々使えます。ヘルプを参照してください。

著者プロフィール

川口耕介(かわぐちこうすけ)

Sun Microsystems, Inc.のシニアスタッフエンジニア。主としてXMLとのそのスキーマ言語関係の仕事をし,JAXB, JAXP, JAX-WSなどの仕様策定・実装に携わった。仕事の他にも,主にjava.netに多数の趣味のプロジェクトをホストしている。Hudsonは趣味のプロジェクトとして開始したが,今では本業の一部。米国カリフォルニア州在住。

URLhttp://www.kohsuke.org/