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

第3回 Hudsonによるチーム間の連携

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

ファイル指紋を記録

こうして互いに依存する多くのプロジェクトを使い,1つのプロジェクトで作ったバイナリを他のプロジェクトで利用していると,どのビルドで作られたバイナリがどこでテストされているかをきちんと追跡することが重要になってきます。例えば,テストプロジェクトの#50でリグレッションが発見されたとしましょう。このテストがテストしたバイナリのビルド番号がわからなければ,どの変更が原因でこの問題が発生したのかをきちんと追跡できません。

この問題は,中間に入るプロジェクトの数が多くなるにつれて深刻化します。例えば,何とかテストの失敗はビルド#100に起因するとあたりをつけたとしましょう。さて,このビルド#100での変更は,社内の共通ライブラリを新しいビルドに更新したことによるビルドだったとします。となると,このテストの失敗の原因を特定の変更に結びつけるには,今度はこのライブラリに加えられた変更を追わなくてはいけません。このような作業は,正確に行うのは人間には向いていない作業です。

Hudsonにはこれを正確に行うために「ファイル指紋」という概念があります。ビルドの終了後,Hudsonは指定されたファイルのMD5チェックサムを計算し,そのファイルがビルドに登場したことを記録しておきます(さらにタイムスタンプを見ることで,ファイルがビルドによって作られたのか外部から持ち込まれたのかを推定します⁠⁠。これをビルド側とテスト側と両方で行うと,どのビルドで作られたバイナリがどのテストで利用されているのかの正確な情報がHudsonに蓄積され,この情報がUI上に色々な形で表示されるようになります。この仕組みは,ビルのあちこちに監視カメラを設置するのに似ています。ある人がビルの中をうろうろしていると,どのカメラに何時にその人が登場するのかを比較する事で,行動の様子に付いて多くの知識が得られます。これをビルドの成果物に大して行うのがファイル指紋の追跡です。

この機能の設定は「ビルド後の処理」>「ファイル指紋を記録」で行います。ビルド側では単に成果物の指紋を記録しておけばよいだけなので,テキストフィールドは無視して「保存された成果物の指紋を記録」をチェックしましょう。テスト側では,ダウンロードしたビルドの指紋を記録するので,テキストフィールドを使ってダウンロード先を指定します。このように設定しておくと,ビルドやテストを見ている時に,お互いの対応関係が下図のように表示されます。

画像

また,ファイルの右脇のアイコンをクリックして,そのファイルがどこで使われているかの一覧を表示させる事もできます。下図の例では,JAXB RIがライブラリとしてJAX-WS RIとWSITで使われているのですが,JAXB RIビルド#556がJAX-WS RI及びWSITのどのビルドで利用されているのか表示されています。

画像

さらに,ビルドページの左側から「指紋を見る」を選べば,このビルドで指紋が記録されたファイルの一覧と,それらに出自が表示されます。

画像

例えば,この例では同じくJAXB RIビルド#556で使われているライブラリの出自などがわかります。

このようなトラッキングを利用することで,問題が見付かった時に原因をするのが容易になります。例えばこのJAXB RIのビルドでライブラリzephyrに関係ありそうなバグが見付かった時,この記録をみて,ああ,zephyrのビルドは#154だけれども, zephyr #160でどうもこの問題は修正されているようだからzephyrチームに連絡する前に最新版に変更してみよう,などと判断することができます。あるいは,テストで新しいリグレッションが見付かった時に何か依存関係に変更はあったか調べることも出来ます。

テストの分割

先に,1サイクルの時間を短縮することがとても重要であるという話をしました。そこで,テストの見かけの実行時間をさらに短縮するために,ビルド・テストと2つに分けるだけでなく,テスト自体を複数のジョブに分割するようにしましょう。

例えば,筆者の職場では,開発チームが作ったテストを(実際にはユニットテストでなくても)ユニットテスト,テストチームが作ったテストをSQEテスト, JCP規格との互換性をテストするのがTCKテスト,といった具合に,1つの製品に対して幾つかの全く異なったテストセットが存在することが普通です。このような場合には,これらのテストをそれぞれ別々のジョブとしてセットアップすれば,これらが全て同時並行に実行されるので,見かけのテスト時間が短縮されます。

画像

また,テストがある程度以上の規模になると,1つのテストセットがより小さいテスト群から構成されているのも普通かと思います。このような場合にも,テスト群を全て連続して一気通貫に実行するのでは無くて,個別に実行することで並列度を増すことができます。また,同一のテストを複数の条件下(例えばサポートしているデータベースそれぞれで,あるいは対応しているJDKバージョンそれぞれで,など)でテストする場合も,分割が容易です。このようにしてテストを分解して実行する場合は,フリースタイルプロジェクトを使うと,ほとんど似たりよったりのプロジェクトが沢山できてしまって管理が面倒になるので,このような状況に特化したマルチ構成プロジェクトを使うと便利です。マルチ構成プロジェクトの詳細については連載の後の方で解説する予定です。

テスト結果の集計

実行時間の向上のためにテストを分割すると,今度はテスト結果が複数のジョブに散らばってしまって,結果を一覧するのが大変になります。こうした場合向けに,Hudsonには下流のプロジェクトのテスト結果を自動的に集計する機能があります。上流・下流プロジェクトの関係が既に構築されていて,ファイル指紋のトラッキングが既に行われていれば,これは設定画面から「下流プロジェクトのテスト結果を集約する」を選ぶだけです。

画像

著者プロフィール

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

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

URLhttp://www.kohsuke.org/