チーム開発に向けたビルド環境の構築：開発プロセス再入門（5）（2/3 ページ）

ビルドの手順

　antについては良いドキュメントが多く知名度も高いと思いますので、ここではantスクリプト（build.xml）に関する詳細な解説は避けますが、典型的なantスクリプトにより実行されるターゲットの責務を順に紹介してみます。ここに説明する手順を実施できる環境を整えることを指して、ビルド環境を構築する、といいます。ここに説明するのは、ビルド担当者の責務そのものでもあります。

　weeklyでビルドを行っているソフトウェア開発プロジェクトでは、週に1度のビルド日がやって来ると、ビルド担当者の出番となります。ビルドを開始するときは、ビルド担当者はその旨を開発者に通知します。このビルドで完了する予定の作業項目を完了できていない開発者は、ビルド担当者を拝み倒してビルドの開始を少しだけ待ってもらうことができます。ビルド担当者を拝んだ開発者は、急いでソースコードの修正を完了し、これを構成管理ツールにコミットしなければいけません。ビルドが開始されたら、この作業が終わるまで、開発者はソースコードを構成管理ツールにコミットすることはできません。

［ビルド番号を更新する］

　ビルド番号が記述されたリソースファイルを更新して、ビルド番号をインクリメントします。IDEには、Borland Delphiなどのように、ビルドするたびにビルド番号を自動でインクリメントしてくれるものがあります。しかし、ビルド環境でなく、各開発者の開発マシンでビルド番号が自動でインクリメントされてもあまりうれしくありません。antのタスクには、自動的にリソースファイル内のビルド番号をインクリメントしてくれる、そのものずばりのBuildNumberタスクというのがあります。が、ビルドマシンの環境では、ビルド計画どおりの番号のビルドを構築しなければならないため、ビルドマシンでビルド（に失敗）するたびに勝手にビルド番号がインクリメントされても困ります。そこで、BuildNumberタスクを含むターゲットをほかのターゲットと分離しておくとよいでしょう。ほかのターゲットの実行に先立って、一度BuildNumberタスクを含むターゲットを実行することで、ビルド番号のインクリメントという作業を自動化できます。

　あるいは、バージョンリソースファイルがJavaのではなくWindowsのリソースファイルであったり、また複数のモジュールをビルドする必要がある（複数のバージョンリソースファイルをメンテナンスする必要がある）のであれば、バージョンリソースファイルを自動生成するantの独自タスクを作成しておくのも有用です。

　さらに、更新したバージョンリソースファイルを、構成管理ツールにコミットするところまで自動化してもよいでしょう。構成管理ツールの操作も、antのタスクで行うことができます（すぐ下に紹介します）。

　以降のターゲットは、連続して実行させても構いません。

［構成管理ツールから、最新のソースコードを取得する］

　ソースコードをコンパイルする前に、最新のソースコードをソースコード管理リポジトリから取得します。リポジトリにcvsを利用しているのであれば、cvsタスクを使います。Microsoft Visual SourceSafeを利用しているのであれば、vssgetタスクを使います。また、最近認知されつつある新しい構成管理ツールSubVersionにも、antタスクが用意されているようです。

［ソースコードをコンパイルする］

　Javaのソースコードをコンパイルするなら、javacタスクを使ってJavaコンパイラを起動します。簡単ですね。開発言語がMicrosoft Visual BasicやBorland Delphiなどであれば、execタスクを使ってコマンドラインコンパイラを呼び出すか、コマンドラインコンパイラを呼び出す独自のantタスクを書いてビルド環境を構築しましょう。antにより自動的に展開されるファイル名もしくはファイルセットを使って、ライブラリパスを分かりやすくantスクリプトに記述できるようにしたり、詳細なログとエラー情報を出力できるようにしたりと、独自タスクを記述するといろいろ良いことがあります。このようなRADツールで、きちんとビルド環境を用意してソフトウェアを開発しているプロジェクトは非常に少ないのではないかと想像しますが、実際のところ皆さんどうされているのでしょうか。

［ソースコードからドキュメントを生成する］

　ソースコードに含まれるコメントからドキュメントを生成するツールとして、Javaにはjavadocという標準のツールがあります。javadocタスクを使って、ドキュメントを自動生成しましょう。Java以外の開発言語にも、多くのドキュメント生成ツールがあります。独自のIDEを持つ高機能なものもありますが、そのほとんどがコマンドラインから利用できるツールを含んでいます。execタスクか、もしくはantの独自タスクを書いてこれを呼び出してください。フリーで利用できるものや、商用のものもありますので、探してみるとよいでしょう。

　このようなドキュメントは、ビルド番号を管理したうえでのテストの対象とはなりません。そもそも、このようなドキュメントにはビルド番号を付加することもできません。このため、javadocを読まされる開発者は、単純にこのドキュメントが新しければ新しいほど幸せになれます。ユーザーに納品する対象としてjavadocドキュメントを生成する必要があるなら、weekly buildにおいてもjavadocを生成するのは価値がありますが、ドキュメントを生成するantターゲットは各開発者が各自のマシンでも利用できるように用意しておくか、もしくはjavadocを含むターゲットだけはdailyでビルドする、などの工夫が必要です。

［配布パッケージを作成する］

　クラスファイルをアーカイブしてjarファイルを生成したり、インストーラを作成することで、配布パッケージを作成します。この配布パッケージをインストールイメージということもあります。また、この作業を指してキッティングということもあります。開発言語がJavaであれば、jarタスクもしくはzipタスクなどを使うとよいでしょう。あるいは、InstallShieldなどの外部ツールを呼び出す必要があるかもしれません。このターゲットも、ソフトウェアのドメインによって具体的な処理が大きく異なってきます。

［ビルドのインプットとなったファイルにタグを打つ］

　このビルドとまったく同じビルドを後で再現できるように、ビルドのインプットとなったファイルにタグを打ちます。タグの名前には、<製品名>_<ビルド番号> のようなものが良いでしょう。自動化するなら、cvsタスクやvsslabelタスクが使えます。ビルドに失敗して、リビルドした場合には、失敗したときに打ったタグを上書きしてタグを打ち直すことを忘れないでください。

［xUnitなどで自動化されたテストを行う］

　自動化された単体テストがあれば、ビルド直後に実行してしまいましょう。JUnitを使うなら、junit/junitreportタスクが利用できます。ほかにも、Mercury WinRunnerやRational Robot、Segue QA Partnerなど、GUIを持つアプリケーションの統合テストを自動化する商用のツールもあります。あまりにも結果が芳しくなければ、このビルドはQAにリリースする候補にはなりません。修正すべきところを修正して、リビルドします。もちろん、このリビルドに際しては、ビルド番号を再度インクリメントする必要はありません。自動化されたテストの実行に時間がかかるのであれば、QAリリース日時よりもビルド日時を早めに設定して十分な時間を確保し、QAリリース前に自動化したテストが実施し終えることができるようにします。

［開発チームに候補ビルドをリリースする］

　候補ビルドをしかるべき場所（ファイルサーバなど）にコピーします。もちろん、QAチームに見える場所ではいけません。このターゲットは、自動化しなくても十分な場合もよくありますが、自動化するならcopyタスクやftpタスクが役に立ちます。コピーしたら、開発者に候補ビルドができたことをアナウンスします。これを自動化するなら、mailタスクやsoundタスクです。より頻繁にビルドをリリースしながら開発するときは、自動化しておくのもいいでしょう。開発者は、候補ビルドのリリースを受けて、これを自分の環境にインストールし、自分が新しく実装した部分が適切に実装されているか、修正した不具合が正しく修正されているかどうかを確認します。

　連続して自動実行させていいターゲットは、ここまでです。候補ビルドで致命的な問題が見つからなければ、これをそのままQAにリリースします。

［ビルドの成果物を保存する］

　上記の手順により構築した成果物を、しかるべき場所に保存します。開発言語によっては、不具合の原因を調査しやすくするために、ビルドの過程で出力された中間ファイル（マップファイルなど）を構成管理ツールにコミットして管理することがあります。あるいは、ビルドの成果物（配布パッケージ）そのものも構成管理ツールで管理することがあります。これを自動化するには、cvsタスクやvssputタスクを使います。

　ただし、正しく構成管理ツールのタグを管理していれば、まったく同じビルドを後日に再現可能ですし、ビルドの成果物は一般にソースコードのサイズよりも大きくなるので、ビルドの成果物をすべて保存すると、ディスク容量を圧迫することになります。古いビルドは、日がたつと（新しいビルドのリリースに伴い）不要になっていきますから、構成管理ツールにはコミットせずにファイルサーバ上にだけ管理し、古いものから削除していく、あるいは外部メディアに移動するといった管理をすると良いでしょう。ただし、ソフトウェアの規模によってもビルドの成果物の管理方法は変わってくると思います。中途半端に古いビルドは、不具合の再現のために残しておかなければならないこともよくあります。

［QAチームにビルドをリリースする］

　ビルド担当者は、開発者が記述したリリースノートを取りまとめてビルドに添付します。これらをQAチームに見える場所に公開し、QAチームにリリースをアナウンスします。

　ビルド担当者は、ビルドの作業をどこまで自動化すべきか、よく検討してみてください。