メディア

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

» 2004年08月17日 12時00分公開

ビルド手順書の記述

　ビルド担当者は、自分が不慮の事故（あるいは、故意の転職）などで突然いなくなっても、ほかの人が作業を引き継ぐことができるように準備しておかなくてはいけません。ビルド担当者が風邪をひいて休んだからビルドができなかったのでは話になりません。さすがに、ビルド手順書を記述する作業を自動化するというわけにはいきませんが、やはりantによる支援を受けることはできます。

　build.xmlにおける各ターゲットにdescription要素を用意し、各ターゲットが自動化する作業についての説明をbuild.xmlに記述しておきます。こうしておくと、ant -projecthelpを実行することで、実行されるターゲットのdescription（説明）を順に表示させることができ、なかなか便利です。build.xmlにエンコーディングを指定しておけば、descriptionに日本語を記述することもできます。開発するソフトウェアの規模が小さければ、これをそのままビルド手順書の代用としてもいいかもしれません。

　ただし、ビルドに際しては、そもそもどのターゲットを実行したらいいのか分からない、なんてことでは困ります。また、ビルド手順書はビルド環境の構築手順（ビルドに必要な各ツールのインストール手順など）に加えて、各開発者のマシンにおける開発環境の構築手順についても説明するべきです。antスクリプトのdescriptionの記述に加えて、別にきちんとしたビルド手順書を用意することをお勧めしておきます。

　ビルド環境は、ビルドのリリースを繰り返すたびに少しずつ洗練され、自動化された部分やビルドすべきモジュールなども増えていくはずです。それにつれて、ビルドの手順も変わってきます。ビルドの手順書を常に最新の状態にメンテナンスする作業も、ビルド担当者の責務です。

複数のモジュールをビルドしなければならないときは

　1つの製品の中に、複数の実行可能プログラムが含まれることは非常によくあることです。これらのビルドプロセスを管理するのは、なかなか面倒です。最も簡単な方法は、すべてのモジュールに同一のビルド番号を振って、これらを同時にビルドしてしまうことです。先にも述べましたが、この場合にはバージョンリソースファイルのメンテナンスをantにより自動化した方が工数を圧縮できますし、手違いも減らせます。

　しかし、ソフトウェアをビルドし直してしまったら、基本的にはテストもすべてやり直さなければならないため、修正したつもりのないモジュール、安定したモジュールについてはビルドしない方が賢明です。すると、それぞれ異なるビルド番号の実行可能モジュールが、同一の配布パッケージにキッティングされることになりますが、これはこれで管理が面倒です。どの配布パッケージにどのビルド番号の実行可能モジュールが含まれるのか、この配布パッケージ（インストールイメージ）に添付されるリリースノートに記入しておく必要があります。また、構成管理ツールにおいて、これらのモジュールのソースコードがすべて同じブランチで管理されていればそんなに難しくありませんが、そうでない場合にはさらにビルドの手順が面倒になります。この辺りも、ソフトウェアのドメインによって適した方法が変わってくるでしょう。皆さんが開発するソフトウェアに一番良いビルドプロセスを見つけてください。

QAリリース後に、致命的な不具合を発見したときは

　よほど致命的な不具合でなければ、それは制限事項としてそのままにし、ビルドをリリースし直すことはしません。余計な工数が増えてしまいますし、大した問題でなければ、次のビルドで修正すればいいからです。

　しかし、予定していたテストが実施できないなど、その週のQAチームの作業に支障が出てしまうような不具合が発見されたときには、ビルドをリリースし直さざるを得ません。開発者が、すでに次のビルドのために修正したソースコードを構成管理ツールにコミットしてしまっていたら、先に打っておいたタグ位置からブランチを作り、ソースコードをフォーク（分岐）させます。そして、不具合の修正に必要なファイルだけを修正してそのブランチにコミットし、ビルド環境ではそのブランチからソースコードを取得してビルドをします。これにより、不要なファイルの修正が含まれない形でリビルドを行い、開発者によるQAリリース候補のビルドのテストの工数が無駄に大きくならないようにします。また、新しい候補ビルドのテストを早急に完了させ、すぐにQAチームにリリースできるようにします。サブブランチ側にコミットしたソースは、メインブランチ側にもその修正を反映させるのを忘れないでください。

QAリリース後に、ビルドの差し戻し（リビルド）を何度も要求されてしまう

　これは、QAリリースの候補ビルドでの開発者によるテストが不十分だったり、そもそも開発中のソフトウェアがQAによるテストに耐え得る品質に達していないときによく起こります。ビルドを差し戻した場合には、同じビルド番号のビルドを作り直すわけですが、このとき重要なのは、QA全員が不正となったビルドをきちんとアンインストールし、廃棄することです。そうでなければ、不具合報告書の品質に問題が出てしまいます。ビルドの差し戻しがあまりにも頻繁に起きるようでは、不正なビルド番号のビルドがたくさんQAに漏れてしまい、QAは自分が正しいビルドを使ってテストしているのかどうか、よく分からなくなってしまいます。このようなときには、ビルド番号とは別に、リリース番号を導入し、ビルドを差し戻した際にはビルド番号をインクリメントしてしまうことに決めておくとよいでしょう。

　このとき、ビルドのリリース計画も、ビルド番号ではなくリリース番号に基づいて計画するようにします。weeklyでビルドをリリースする場合、リリース番号は絶対に週に1ずつしかインクリメントしないが、ビルド番号は数回インクリメントするかもしれないという形で運用し、ソフトウェアのバージョンを

メジャーバージョン番号.マイナーバージョン番号.リリース番号.ビルド番号

という形で表すようにします。リリース番号をインクリメントしたとき、ビルド番号を1にリセットする運用をするときもありますし、ビルド番号をリセットせずにきちんと数えていく場合もあります。リリース番号をインクリメントしたときに、ビルド番号を1にリセットするような運用にすると、そのリリースが何回差し戻されてリビルドされたのかが分かります。一方、ビルド番号をリセットせずにちゃんと数えていくと、ビルド番号だけでビルドを一意に特定できるというメリットが得られます。

　リリース番号を導入したからといって、QAリリース後に何度もリビルドしてリリースし直すのは、やはり感心しません。テストの対象となるソフトウェアのバージョンは少ない方が楽ですし、開発者がビルドをリビルドする工数も、QAがビルドをインストールし直す工数も無駄になるからです。

　もちろん、ここで示した以外のバージョン情報／ビルド番号のフォーマットやそれをインクリメントする方法があります。ビルド番号を付けるポリシーは、ソフトウェアのバージョンを管理する上で非常に重要です。みなさんの開発スタイルに合ったバージョン管理のポリシーを探してみてください。

　次回は、ビルドの位置付けについて説明します。お楽しみに。

この記事に対するご意見をお寄せください

managemail@atmarkit.co.jp

著者紹介

▼津田義史

　5年間、某外資系ソフトウェアベンダでパッケージ製品の開発とグローバリゼーションに従事。その後、オブジェクト指向技術に疑問を感じ、2000年に豆蔵に入社。現在は、コンサルティングを通して、間違った開発プロジェクトをみることが多く、改めてソフトウェアというものが難しい仕事であることを実感する毎日。興味の対象は、C++のテンプレートを使った静的な多態性の活用だが、最近はC++のコードを書く機会そのものが少ない。

「開発プロセス再入門」バックナンバー

前のページへ 1|2|3 　　　　　　