CIツールHudsonを使いこなす

XPのプラクティスの一つが常時統合(CI・Continuous Integration)。
別名、デイリービルドと言われる。
第2世代CIツールと言われるHudsonを使って運用して、常時統合の概念について改めて書く。
#Hudsonの全機能はまだ使いこなせてないので念のため。

【1】バージョン管理(SCM)＋常時統合(CI)＋テスト駆動開発(TDD)で、初めてアジャイル開発が可能になる

【元ネタ】
バージョン管理と常時結合

豆蔵：継続的インテグレーション（CI）をしましょう

Subversionでbranches/tags/trunkでソース管理したら、次に行うべき環境構築はビルド環境。
Javaなら、Ant/Mavenでワンクリックでビルドできるようにスクリプトを作る。

今でもビルドする時に、Eclipseから手作業でビルドしているプロジェクトもままある。
ローカルマシンで手作業でビルドする弱点は、そのローカルマシンが使えなくなったらビルドできなくなること。
普通はプロジェクトリーダーがビルドとリリース作業を担当するから、彼の開発環境特有のノウハウがあったり、JDKのバージョンがマシンごとに違ったり、彼が夏季休暇でいなくなると、緊急リリースできなくなる。

だから、ビルド環境は開発サーバーで構築したい。
そうすれば、誰でもリリース可能になるし、誰がビルドしても同じバイナリのモジュールが作れる。
ビルドスクリプトもSVNでバージョン管理しよう。
そのビルドスクリプトに、JavaDoc生成、JUnit実行、各種レポート出力もあると、リリースするモジュールを作るだけでなく、納品ドキュメント一式も出力するといった作業も一発で自動化できる。

ビルド環境ができたら、SVNコミットするたびに常時統合するようにしよう。
常時統合の最大の利点は、SVNリポジトリがいつでもリリース可能である状態を保てること。

複数の開発者が一つのシステムを開発する時、インターフェイスが合わないことも知らずにSVNコミットする時がある。
常時統合するビルド環境があれば、ビルド後コンパイルエラーとしてすぐに通知できる。
更には、ビルド時に、コンパイルエラーだけでなく、テストユニットが全て通ることも必須にすれば、物理的だけでなく、仕様を満たすという意味で論理的にも正しいモジュールが作れることを意味する。
昨今のCIツールでは、画面上で結果を表示したり、メール通知したり、RSS表示などで通知してくれる。

つまり、常時統合の概念がないウォーターフォール型開発では、

コーディング→単体テスト→ビルド

の順に進んで、最後でエラーが分かるのに対し、常時統合環境ならば、ビルド時にJUnitを通過させることで単体テストも通ったプログラムかどうかチェックできる。

SCM＋CI＋TDDで初めて、プログラマ主体のアジャイル開発環境ができあがる。

【2】Hudsonはすごくお手軽で強力なCIツール

CIツールは、Continuum、CruiseControlなどあるが、第2世代CIツールと言われるHudsonを使ってみたらすごく使いやすい。
下記の記事が詳しい。

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

Hudsonの最大の特徴は、日本人技術者が作っているので日本語化されていること。
又、warファイルで提供されているので、Tomcatへデプロイすればすぐに操作できるのでインストールが簡単。

上記の記事を読みながら、まだ使いこなせてないが、興味深い機能について下記にまとめる。

【3】Hudsonの特徴～ビルドプロモーション

Hudsonを使ったアジャイルな開発入門
第4回　プラグインを使う
ビルドプロモーションとプラグイン

Hudsonを使ったアジャイルな開発入門
第4回　プラグインを使う
シナリオ

大規模プロジェクトで複数の開発チームでビルドしているとする。
その場合、複数のビルドモジュール(例えば、jar又はWindowsのDLL)を作り、それらを一つの実行ファイル(例えば、war又はWindowsインストーラ)にまとめることが多いだろう。

大規模プロジェクトの成功が非常に難しい理由の一つに、ビルドプロセスがうまく運用できない点がある。
例えば、チームAが作ったライブラリにインターフェイス追加の仕様変更があったのに、他チームが対応していなければビルド時にコンパイルエラーになる。
でも実際は、新規のインターフェイスに対応するのは後回しでも良い時があったりする。
チーム間のコミュニケーションで風通しが悪いと、よく起こる。

あるいは、バグ修正や仕様変更などでインターフェイスが大きく変わってしまったけれど、他チームでは、一部の新しいインターフェイスだけ欲しい時がある。

また、ビルドを通した時に、ビルドは成功するがいくつかのUnitTestは通らないけれど、そのビルドモジュールが他チームでは開発上必要な場合もよくある。

そんな時に、ビルドプロモーション機能を使う。
つまり、ビルドモジュールに、優良・不良・最終用などの状態で色付けする。
Hudsonでは、ファイル指紋という機能があり、ビルドモジュールを一意に峻別してバージョン付けすることもできる。

特に昨今のWebシステム開発はスピード重視なので、完全なビルドモジュールでなくとも、一部のインターフェイスが通るだけのライブラリがあれば、サクサク開発できる時も多い。

上記の記事では、下流ビルドのチームが上流ビルドのチームへ、これこれのバグを修正したモジュールだけ欲しいと依頼して、ビルドしたライブラリを作ってもらうという話がある。
そんな時に使えるだろう。

【4】Hudsonの特徴～分散ビルド

Hudsonを使ったアジャイルな開発入門
第3回　Hudsonによるチーム間の連携
分散ビルド

ビルドするライブラリが多くなると、最終形式のリリースモジュールを作るまでに1時間近く実行時間がかかる時がある。
特に大規模プロジェクトほどそうなるだろう。
ビルドに時間がかかると、開発者はソースコミットが慎重になり、プロジェクト全体の活動が低下して進捗がどんどん遅れる。

Hudsonには分散ビルドという機能があり、複数のビルド環境と連携して、ビルド作業を並列に実行することができる。
つまり、ビルド作業を直列ではなく並行実行することで、見かけ上のビルド時間を減らす。

詳細な設定方法は上記の記事に書かれているが、大規模プロジェクトでは非常に有効な機能だ。
特に昨今のWebアプリのように、クライアントアプリとサーバーアプリで共通ライブラリをくくりだしてビルドする場合、たった1行のソース変更で、ユニットテストも通すからビルドが1時間かかることも稀ではない。
サーバーはとても安くなったので、古いサーバーをビルド環境にして並列ビルドできれば、複数のチームによる開発でもアジャイル開発できるはずだ。

【5】Hudsonの特徴～マルチ構成プロジェクト

Hudsonを使ったアジャイルな開発入門
第5回　高度なプロジェクトタイプ
マルチ構成プロジェクト

この機能は、ハードウェアやJDK等のバージョンは違うけれど、同じビルド作業を行う時、同一のビルド設定情報を使って、複数の環境でもビルドできるようにすること。

本番環境のJDKのバージョンアップ、ハードウェアのリプレースでOSなどの環境が変わった時、この機能を使えば、Hudsonが色んな構成方法でビルドして結果を出力してくれる。

特にWindowsアプリのように色んなOSでビルドできることを確認したい時、あるいは、WebアプリでJDKのバージョンアップしてもきちんとビルドできるかを試したい時に使えるだろう。

ハードウェアやJDKのバージョンアップは、長期間続くプロジェクトでは避けられない。
だから、Hudsonの上記の機能は非常に使える。

【6】HudsonとBTSを連携する

昨今のBTSではコミットログにチケットNoを書くと、BTSチケットとソースリビジョンが紐づけできる環境がある。
Hudsonでも、ビルド結果にソースのコミットログを表示するので、プラグインを入れると、コミットログのチケットNoからBTSへリンクする機能がある。
これはすごく便利だ。

TracLightningでは、Hudsonが既に組み込まれている。
他にも、Bugzilla、Mantis、Trac、JiraなどのBTSと連携するプラグインがある。
残念なことに、RedmineはHudsonと連携するプラグインがない。
単にURLを設定するだけなので簡単だと思うが。。

常時統合という概念を生み出したXP。
CIツールとBTS、バージョン管理を上手に使えば、アジャイル開発を簡単に楽しく実現できるはずだ。