Pulseでビルドステータスを追跡する
Pulseは、ソースリポジトリを監視して、だれかがコミットを行うたびにビルドおよびテストのサイクルを開始するビルドサーバだ。Pulseを使えば、バージョン管理システム内にある最新のソースのコンパイル状況や、単体テストおよびシステムテストの経過をたえず把握できる。さらに、パーソナルビルド（Personal Build）という機能により、チェックアウトしたソースの作業用コピーのビルドやテストが行えるので、セントラルリポジトリに対して変更をコミットする前に、コードに問題がないか確認することができる。
Pulseのようなサービスを好まない開発者もいる。コードをチェックインした場合にリグレッション（回帰）テストの中断やほかのメンバとのやりとりが必要になったりするからだ。だが、プロジェクトの回帰テストを実行したうえでソースのコミットができれば、開発者はメインのソースツリーに対するコミットを行う前にコード変更の影響を把握できる。
Pulseのインストール手順については、PulseのWebサイトに詳しい説明があるので、ここでは触れない。今回、Pulseのバージョン2.0.xとバージョン1.2.59の両方を64ビット版Fedoraマシンで試したが、2.0.xのほうはインストール中のデータベース作成が行えなかった。また、Pulseの起動によって現れるWebインタフェースでは、パーソナルビルドの実行を除くすべてのタスクで8080番ポートが使用される。
少人数のチームやオープンソースのプロジェクトには、フリーのライセンスでPulseが提供されている。しかも、オープンソースコミュニティ向けのライセンスでは、プロジェクトあたりのユーザ数に制限がない。なお、個人的にはautotoolsによるビルドやDejaGnuによるテストがデフォルトでサポートされていることを期待していたのだが、Pulseはそのいずれも明示的にはサポートしていない。
ビルドに関しては、Ant、Boost Jam、GNU make、Maven, Xcode、それにカスタムのビルド設定がサポートされている。テストについては、boostリグレッション、CppUnit、OCUnit、CUnit、JUnit、UnitTest++、Mavenがサポートされている。
Pulseを使ってCVSにあるautotoolsのプロジェクトをビルドするには、ちょっとした工夫が必要だった。具体的には、GNU makeによるビルドを参考にして設定を行い、「projects」→「ferrisloki」→「configuration」で開くウィンドウ上でカスタムのビルドタイプへと変換した。このとき、「projects」は最上位のメニューから、libferrislokiは既知のプロジェクトの1つとして選択し、「configuration」はそのサブメニューから選択する。動作確認にlibferrislokiを選んだ理由としては、なじみのあるコードベースであること、短時間でビルドできること、すでの私のローカルCVSリポジトリに入っていること、標準的なautotoolsの慣例に従っていることが挙げられる。
libferrislokiのビルドに使ったカスタムのPulse用ビルドファイルの内容を以下に示す。ここで参照しているブートストラップファイルは、多くのオープンソースリポジトリに含まれているautogen.shファイルと同様の役割を果たす。このビルドファイルの中身は、標準のGNU makeによるPulse用ビルドファイルに、最初の2つのcommandエレメントとartifactエレメントを追加したものになっている。Pulseでは、ビルドによって生成されるファイルやディレクトリをアーティファクト（artifact）と呼ぶ。アーティファクトの情報は収集され、Webインタフェースから参照できる。各種アーティファクトを残しておくことで、変更の箇所や特定のテストの出力そのものをあとで確認することができる。
また、デフォルトの作業ディレクトリ（カレントディレクトリ）は、ソースコードのチェックアウト先（つまり、configure.acを含むディレクトリの1つ上）となっていた。
追加した2つのcommandエレメントは、それぞれブートストラップスクリプト（autogen.shのようなもの）の実行と、そこで生成された「./configure」スクリプトの実行を行う。また、追加したartifactの行は、ビルドごとに配布用tarballを得るためのものだ。なお、私が手を加えた部分のコードは太字にしてある。
<?xml version="1.0" encoding="UTF-8"?>
<project defaultRecipe="make build">
<recipe name="make build">
<command name="autotools-bootstrap">
<executable exe="./bootstrap" args="" working-dir="libferrisloki" />
</command>
<command name="autotools-configure">
<executable exe="./configure" args="" working-dir="libferrisloki" />
</command>
<command name="build">
<make makefile="Makefile" targets="all dist" working-dir="libferrisloki" > </make>
<artifact name="tarball" file="libferrisloki/ferrisloki*.tar.bz2"/>
</command>
</recipe>
</project>
GNU makeによるビルドをこうしたカスタムのビルドに変換することの問題点は、いったん変換してしまうとPulseのWebインタフェースを使ってアーティファクトを指定できなくなってしまうことだ。アーティファクトを得るには、Pulseのビルドファイルを（Webインタフェース上で）編集して、artifactエレメントを手作業で追加する必要がある。
ブートストラップスクリプトは、autobookのものを参考にしており、次のようになっている。
$ cat bootstrap #!/bin/bash mkdir -p macros libtoolize --force aclocal -I macros automake --gnu --add-missing autoconf
先ほどのPulseのカスタムプロジェクトとこのブートストラップファイルをCVSに用意することで、libferrislokiをうまくビルドすることができた。また、「make dist」によるtarballが、いつでもダウンロード可能なアーティファクトとして得られた。
パーソナルビルドを実行するには、いくつかの設定手順を踏む必要がある。設定はごく簡単で、ホームディレクトリ下のドットファイルに保存されているグローバル設定と、カレントディレクトリに保存されているプロジェクト特有のオプションを用いる。後者は、チェックアウトした作業用ソースコードの最上位ディレクトリから「pulse personal」コマンドを実行することを意味する。
$ ~/pulse-1.2.59/bin/pulse personal No pulse server configured. Configure one now? Yes/No [default: Yes]> Pulse URL [e.g. http://pulse:8080]: http://localhost:8080 Pulse user [default: ben]: Storing Pulse server details in '/home/ben/.pulse.properties'. No pulse project configured. Configure one now? Yes/No [default: Yes]> Pulse project: ferrisloki Build specification: default Storing project details in '/tmp/cvstest/libferrisloki/.pulse.properties'. Pulse password:
チェックアウトしたソースツリーのパーソナルビルド向けの設定が済むと、「pulse personal」とするだけでパーソナルビルドを実行できるようになる。事前にExtensions.hhヘッダファイルに「#warning」と追記したうえで、下記のコマンドによってパーソナルビルドを実行し、変更後もすべて問題なくコンパイルできるかどうかを確かめた。
$ ~/pulse-1.2.59/bin/pulse personal Pulse password: Updating working copy... ? .pulse.properties M src/Extensions.hh Update complete. Getting working copy status... MODIFIED src/Extensions.hh Status retrieved. Creating patch archive... meta.xml files/libferrisloki/src/Extensions.hh Patch created. Sending patch to pulse server... Patch accepted: personal build 1.
「pulse personal」コマンドでパーソナルビルドを開始すると、状況の監視が可能になり、その経過はPulseのWebインタフェースの「dashboard」→「my builds」ページから確認できる。「my builds」ページの表示内容は、標準的なシステム全体のビルドの場合（「projects」→「ferrisloki」→「home」→「current」で開くビルドウィンドウの表示）と同じである。つまり、パーソナルビルドについても、完全なビルドログや設定済みアーティファクト、さらに失敗したテストがあればその情報も確認することができる。
まとめ
カスタムプロジェクトを使わないとautotoolsによるビルドがサポートされないため、Pulseの利用は多くのオープンソースプロジェクトにとって必要以上に敷居が高い。Pulseのドキュメントには、完全なサンプルコードが少しでもあればもっと理解しやすいだろうと思われる部分がいくつかある。設定に手を加えて実行してみたいという人は、設定の断片的な内容しか記されていないドキュメントに不満を覚えるだろう。
とはいえ、パーソナルビルドは、グループ開発環境にとってすばらしいオプションだ。一般的には、自らの作業用コピーを更新したら、その変更内容とほかのソースコードの最新版との間に不整合がないこと、また変更後もすべてのソースがコンパイルできることを確認したうえで、メインのソースリポジトリに対して変更をコミットするのが優れたやり方とされている。Pulseのパーソナルビルドを使えば、変更したコードをほかの開発メンバに渡す前に、システムテストや回帰テストにパスすることも確認できる。ただし、注意すべき点が1つある。それは、パーソナルビルドの開始時点でメインリポジトリに変更があった場合、Pulseがその内容を現在の作業用コピーに反映させてしまうことだ。作業用コピーは、Pulseとは無関係に自分の手で更新できるように、そのままにしておいてくれたほうがありがたい。
Ben Martinは10年以上前からファイルシステムに携わっている。博士号を持ち、現在はlibferris、各種ファイルシステム、検索ソリューションを中心としたコンサルティング業務に従事。
