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

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

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

この連載では,オープンソースの継続的インテグレーション(CI)サーバであるHudsonを利用した,ソフトウェア開発の生産性向上について解説しています。前回の記事では,プラグインを幾つか紹介し,また使って楽しいエクストリーム・フィードバック・デバイスについても触れました。さて,最終回となる今回は,Mavenと連携したりテストを効率よく実行したりするための高度なプロジェクトタイプを紹介します。

Mavenプロジェクトタイプ

さて,本稿では,今まで「フリースタイルプロジェクト」と呼ばれているHudsonの標準的なプロジェクトタイプを紹介してきました。この型のプロジェクトでは,任意のソースコード管理システムと,任意のビルドツールと,更に任意のビルド後処理を組み合わせることができます。この方式では,Hudsonは本質的には何がビルドされているのかまったく理解せず,単に手順を設定されたとおりに実行するだけです。この結果として,どのような種類のプロジェクトにも適用できて,高い汎用性を得ることができますが,他方,その分本質的に必要なもの以上に多くの設定を行う必要があります。何とか,この設定をより簡略化する方法はないものでしょうか。

HudsonのMavenプロジェクトタイプはこの問題を解決する一つの方法です。プロジェクトがMavenでビルドされている場合,ビルドに関する多くの情報(例えば生成されるjarファイル,テストレポート,javadocなど)はpom.xmlに既に書かれています。ビルドツールをMavenに固定する代わりに,この情報を最大限活用して自動化をよりいっそう推し進めるのが,Mavenプロジェクトタイプの基本的な発想です。このモードでは,Hudsonは実行されているMavenの中に監視ツールを配置して,Mavenが何をしているのかを追跡します。 surefireプラグインが実行されてユニットテストが走ったり,あるいはjavadocプラグインが実行されてjavadocが生成されれば,これらを記録する処理を自動的に行います。また,Mavenモジュールの一覧を表示したり,利用されたプラグインの一覧とそのバージョンを記録したりといった,Mavenに固有のユーザーインターフェースもHudson上に表示されるようになります。この結果,フリースタイルプロジェクトでは必要であった多くの設定項目が削減できます。

実際に簡単な例を見ましょう。Hudson自身はMavenでビルドされているので,HudsonをHudsonでビルドしてみます。次の画面は設定画面の主要な部分です。ご覧のように,SubversionのURL と,「clean install」というMavenのビルドフェーズが指定されている他は何の設定もありません。

画像

ところが,ビルドを実際に実行してみると,適切に設定されたフリースタイルプロジェクトと同程度かそれ以上の情報がHudsonによって収集されていることが分かります。以下は,このプロジェクトに含まれるMavenモジュールの一覧です。

画像

テスト結果も自動的に収集されて傾向が表示されます。

画像

生成されたアーティファクトも自動的に記録されています。

画像

実行されたプラグイン・mojo・及びそのバージョンとファイル指紋です。こっちのマシンではビルドできるのにあっちではビルドできないといった,プラグインのバージョンに起因するビルド関係のトラブルシューティングをする時に役立ちます。

画像

この他に,目には見えない部分でも幾つかの処理が自動的にキックインします。例えばPOMの内容から依存関係を計算され,依存しているプロジェクトが Hudson上でビルドされていれば,それらのプロジェクトの間に上流・下流関係が設定されます。POMのを利用していればそれらのメールアドレスに通知も送られます。また,追加のHudsonプラグインを導入する事でHudsonが反応できるMaven mojoの種類が増えます。例えば,FindbugsプラグインをHudsonにインストールしていると,findbugs-maven-plugin が実行されるだけで自動的にfindbugsのレポートが収集されます。

Maven サポートでのもう一つのウリは,事後のデプロイメントです。Mavenの標準の動作では,モジュールが複数あった場合には個々のモジュール毎にビルドとデプロイが繰り返されます。この結果,後ろのモジュールがビルドに失敗した時には,それより以前のモジュールは既にデプロイされてしまっていて,結果としてリポジトリが一貫性の無い状態になってしまうことがあります。HudsonにはMavenのビルドが完全に終了してからデプロイをする機能があり,この問題を防ぐことができます。

また,これと前回紹介したビルド・プロモーションを組み合わせると,より複雑なテスト工程を実行してさらに緻密に動作を検証して,プロモートされたビルドだけをリポジトリへコピーしたりすることもできます。これによって,不安定なビルドが他のユーザーのところへ流出してしまうのを防ぐことができます。

この機能はHudsonの中では比較的新しく,まだまだ改善の余地は沢山ありますが,既に十分に有用な機能になっていると思います。試してみてください。

著者プロフィール

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

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

URLhttp://www.kohsuke.org/

コメント

コメントの記入