メディア

ビルドの位置付けとリリースの順序：開発プロセス再入門（6）（3/3 ページ）

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

[津田義史（豆蔵），＠IT]

stable build

　安定したビルドです。ソフトウェアの品質が安定するまでには、時間がかかるものです。そこで、オープンソースの製品などでは、latest buildのほかにstable buildを公開していることがよくあります。早く新しい機能を試してみたい、多少不安定でも構わないと願うユーザーのためにlatest buildを公開します。これと同時に、新しい機能は取りあえず必要ないけど、安定したバージョンで安心して作業したいと望むユーザーのために、ちょっと古いが安定しているstable buildをダウンロード可能な状態のまま公開しておくわけです。しかし、クローズドな製品を開発しているときはなかなかstable buildというものを意識することはないかもしれません（そもそも、最終ビルドが安定していないことだって、ままあるんですから！）。すべてのビルドが安定して動作すれば幸せですが、初めからstable buildを作ろうと思ってもそうはいきません。そのビルドをリリースしてからしばらく時間がたたなければ、そのビルドが安定したビルドである、と確信を持つことはできません。

　もっとも、ある程度十分な数のテストが自動化されていれば、ビルド直後に「比較的安定したビルドができたみたい」と表明することはできるかもしれません。

candidate build

　候補ビルドです。候補ビルドにもいろいろなものがあります。QAにリリースするweekly buildの候補、各開発フェイズでの成果物となるmilestone buildの候補、最終的にエンドユーザーにリリースするrelease buildの候補などです。

　candidate buildは、本当にそれをリリースしても大丈夫かどうかを検査するためのものです。例えば、QAにリリースするビルドのcandidateができたら、開発者はこのビルドを使って、自分が行った実装や修正が正しく行われているかどうかを確認しなければなりません。正しく行われていなければ、それを制限事項としてリリースノートに記述したり、修正済みと報告した不具合報告書の状態を元に戻したりしてから、そのビルドをQAにリリースします。修正されていなければテストが実施できないような、致命的な不具合が見つかれば、ソースコードを修正して再度候補ビルドを作成し、もう一度最初から確認作業を行います。修正しなければリリースできない不具合のことをshowstopper bug（もしくは単にshowstopper）あるいはblockerなどといいます。

　どのような位置付けのビルドの候補であるかによって、この確認のためのテストに求められる丁寧さも異なります。例えば、release candidate buildは、リグレッションテストの対象となります。リグレッションテストとは、いままでに書かれたテストケースや、いままでに報告されて修正した（はずの）不具合の再現手順をすべてテストし直すことです。リグレッションテストでshowstopperを発見してしまったら、candidate buildをリビルドして、リグレッションテストを最初からやり直します。リグレッションテストについては、次回説明したいと思います。

freeze build

　製品がいよいよ完成に近づき、その製品のある側面を凍結したビルドをfreeze buildといいます。仕様の段階的なフリーズについては、すでに前回までに説明していますが、段階的に凍結していかなければならないのは仕様だけではありません。アプリケーションのさまざまな側面を適切なタイミングで凍結していく必要があります。例えば、feature freeze（機能の凍結）の後、UI freeze（ユーザーインターフェイスの凍結）、code freeze（ソースコードの凍結）と続きます。feature freezeをする時期は、プロジェクトにより大きく異なります。開発の初期の段階でfeature freezeを行えるのが理想ですが、今日のソフトウェア開発では、初期にユーザーの要求を凍結してしまうと、品質の高いソフトウェアを開発するのは難しいといわれています。

　明確にfeature freeze buildやUI freeze buildをリリースしない場合もあります。この理由の1つに、ソフトウェアのドメインによって凍結を意識すべき側面が異なってくるからというのがあります。例えば、エンドユーザー向けのマニュアルを用意する必要がある製品では、どの辺りのビルドでUI freezeをするのか計画しておかないと画面写真を撮影できず、ユーザーマニュアルの作成計画が立てられません。

　ただし、どのようなドメインにおけるソフトウェア開発でもコードフリーズは意識した方がよいでしょう。ソースコードを凍結した後は、安心してリグレッションテストが行えます。もちろん、コードフリーズの後（リグレッションテストの開始後）に、不具合を抱えたプログラマがこっそりソースを修正して構成管理ツールにコミットしたりしないように管理しなければいけません。ほんの少しでもソースコードをいじってビルドをし直せば、その修正に伴うデグレードがないことを確認するために、リグレッションテストはまた最初からすべてやり直しです。自動化されていないテストをリグレッションするのは大変な工数が掛かります。

release build

　最終的にエンドユーザーにリリースするビルドをrelease buildといいます。このビルドを指してfinal build(最終ビルド)、もしくはgold buildということもあります。release buildの候補となるビルドをRC（release candidate）ビルドといいます。また、GC（gold candidate）ということもあります。GCがリグレッションテストや受け入れテストにパスしたら、晴れてゴールドビルドのリリースとなります。ソフトウェア開発プロジェクトでは、このビルドを手に入れるために作業をしてきたのであり、ソフトウェアを開発してきた企業にとって、このビルドはまさに財産（gold）そのものです。

　次回は、テスト計画の立案について説明します。お楽しみに。

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

managemail@atmarkit.co.jp

著者紹介

▼津田義史

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

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

前のページへ 1|2|3 　　　　　　