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

第5回　高度なプロジェクトタイプ

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

マルチ構成プロジェクト

マルチ構成プロジェクトは，ほぼ同一のビルドもしくはテストを数多くの異なる環境で行う場合に適したプロジェクトタイプです。この機能のユースケースは次のようなものです。

  1. ネイティブコードを含むプロジェクトを扱っています。ビルドは，対応している全てのプラットフォームで行う必要があります。
  2. データベースアプリケーションを書いていますが，テストはこのアプリケーションがサポートする全てのデータベースに対して行う必要があります。
  3. ライブラリを書いていますが，テストはSun,BEA,IBMのJDKで，それぞれJDK5とJDK6の両方で行う必要があります。

このような状況では，必要な構成の数だけ個別のプロジェクトをHudsonに設定してもよいのですが，同一の設定を何度も繰り返さなければならず，非効率的です。マルチ構成プロジェクトを使うと，ビルドの設定を一度行い，またどのような構成でビルドを行う必要があるのか（OS，JDKのバージョン，データベース，アプリケーション定義の任意の変数値など）を指定するだけで，Hudsonが自動的にそれらの構成を網羅的に組み合わせてビルドを実行し，結果を集計してくれます。全ての構成で同じソースコードセットが使用され，同一のビルド番号が割り当てられるので，どのビルドにどの変更が入っているのかの追跡も容易です。

筆者の職場では，この機能を使ってMetroウェブサービスライブラリを Windows, Linux, Solarisの３つのOSと，JDK5/6の都合3x2=6つの環境でテストしています。これによって，特定のOSでしか現れないバグがないか検査したり，JDKの動作の微妙な違いによるバグがないか検査したりできるようになっています。この例では同時に６つのテストが実行されますが，このように，マルチ構成プロジェクトを待ち時間なしに捌くためにはそれなりの数のスレーブを利用した分散ビルド環境が必要になります（分散ビルド環境を用意する方法については，本連載の第三回を参照してください）が，このように多くのテストを並行して走らせることによって，より多くのリグレッションを素早く検出することが出来ます。

これも，実際の例を見てみましょう。次の画面は設定画面の主要な部分です。

画像

ビルドの基本的な部分はフリースタイルプロジェクトと一緒で，SCMの設定やビルド手順などはまったく同じですが，幾つかマルチ構成プロジェクト特有の設定項目があり，これらは「構成マトリックス」セクションにあります。

  • もし分散ビルドが設定されていれば，「⁠複数のノード上でのビルド」という設定項目が表示されます。複数のOSで同時にビルドする必要がある場合等には，これを使ってビルドを行うマシンを指定します。個別のマシンを直接指定することもできますが，例えば「Linux,Solaris,Windowsでビルドしたい」といった時にもし条件を満たすスレーブが十分に沢山あれば，マシン名を直接指定する代わりにラベルを利用することで，スケジューリングの自由度を高めることができます。
  • もし複数のJDKが設定されて入れば，JDKをチェックボックスで複数選択することができます。これは，主にテストを複数のJDKを対象に行う時に便利です。何もチェックしないとディフォルトのJDKが使われ，また単に特定のJDKでビルド・テストしたいだけの場合には一つだけチェックします。

これら２つの構成軸に加えて，ユーザー定義の任意の軸を追加することが出来ます。軸は名前と値のセットからなり，例えば，複数のデータベースでテストするなら，名前＝"db"，値＝"mysql postgresql oracle"などと指定します。これらユーザー定義の軸は，環境変数としてビルドに渡されるので，ビルド側でこれらの値に応じて処理を切り替えます。例えば，ビルドがantで実行されていれば，異なるデータベースを使ったテストは次のようなものになるでしょう。

ant -Ddatabase=$db clean test

プロジェクトをビルドすると，次のような画面が表示されます。指定した軸の全ての組み合わせがテストされている事がわかります。

画像

この機能もHudsonの中では比較的新しいですが，既に使えるものになっていると思います。試してみてください。

外部ジョブの監視

最後に紹介するHudsonのジョブタイプは，「⁠外部ジョブの監視」です。この機能は，Hudsonの外で実行されるバッチジョブの実行結果をHudsonの内部に取り込みます。この機能のユースケースは次のようなものです:

  • sendmailやprocmailなどでは，メールが配信された時にプログラムを使って自動処理ができます。が，このようなプログラムが正常に動作しているかを監視するのは煩雑です。
  • 複数のマシン上で幾つものcronジョブが動いています。これらを一括して監視するのが煩雑です。

外部ジョブの監視機能は，ちょうどtimeやstraceのように，他のプロセスをラップします。そして，監視対象のプログラムの標準出力と終了コード，及び実行時間をHudsonにHTTP経由で送信します。

画像

Hudson のモニタリングエージェントはhudson.warに含まれている/WEB-INF/lib/hudson-core-*.jarというファイルです。このプログラムは環境変数HUDSON_HOMEを参照して送信先を決定し，コマンドラインに子プロセスとその引数を受けとります。例えば，次の例は，backup.shを一時間毎に動かして，http://mserver.acme.org/hudson/で動いているHudsonの"backup" ジョブに実行結果を送信します。

HUDSON_HOME=http://myserver.acme.org/hudson/
0 * * * *     export HUDSON_HOME=$HUDSON_HOME; java -jar hudson-core.jar "backup" backup.sh 2>&1 > /dev/null

実行結果の送信に使われるXMLは非常に単純なので，これ以外の方法でXMLを送信すれば，プロセスの実行以外の事もモニタできます。このフォーマットの詳細についてはこちらを参照してください。

終わりに

今日まで，5回に渡ってHudsonの様々な側面について紹介してきました。Hudsonを通して，ソフトウェアの開発工程の自動化と生産性の向上について考えてもらうきっかけになれば幸いです。Hudsonに関するより詳しい情報については，https://hudson.dev.java.net/と，筆者の日本語ブログhttp://d.hatena.ne.jp/kkawa/へどうぞ。

著者プロフィール

川口耕介（かわぐちこうすけ）

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

URL：http://www.kohsuke.org/