![]() |
開発プロセス再入門(6)
ビルドの位置付けとリリースの順序
豆蔵 津田義史
2004/9/8
- - PR -
もちろん、非常に安定してきている(1つのビルドで、発見される不具合の数が少なくなってきている)ソフトウェアの場合には、毎日ビルドを立てて、これをQAにリリースすることもあります。
毎朝に立てるビルドは、morningly buildといいます。
“こっそり”ビルドです。正式な(例えばweeklyの)ビルドが制限事項付きでQAにリリースされたが、QAがその制限事項の解除をどうしても待てないとき、開発者にお願いしてその問題が修正されたビルドを先に作ってもらうことがあります。逆に、開発者がテストを依頼するために予定外のビルドを作成して、こっそり特定のQAに渡すことがあります。このビルド番号が管理されないこっそりビルドのことをprivate buildといいます。
このビルドはビルド番号が正しく管理されたものではないので、ワイドディストリビューションをしないように気を付けなければなりません。特定のQAにだけリリースすべきビルドであって、QAチームにはリリースすべきではないということです。そうしないと、ビルド番号が混乱して不具合報告書の品質に問題が出てしまいます。このビルドは、ビルドマシンできちんとビルドする必要もありません(もちろん、そうしても構いませんが)。開発者の環境でビルドしたものをこっそりQAに渡すので十分です。また、このビルドで発生した不具合に関して、不具合報告書を記述されても困ります。ビルド番号が管理されておらず、ソースコードのタグ付けもされていないので、ほかの開発者やQAが報告された不具合を再現できないかもしれないからです。private buildで再現した不具合は、不具合の発見者がこれをビルドした開発者に口頭(もしくはメール)で伝えるようにするか、正式なビルドで同じ不具合を再現させたうえで、不具合報告書を記述するようにします。
このほか、special build(特別なビルド)といった言葉を使うこともありますが、この言葉の意味は文脈によって異なります。
より大きな反復の単位においてリリースされるビルドです。マイルストーンとは、長い道に1里ごと(mile)に置かれる石(stone)のことで、里程標と訳されます。例えば、「ある重要な機能が実装されて利用可能な状態になる」milestone buildを、開発を通じて何度かリリースすることになります。もちろん、開発期間が短いプロジェクトでは、weeklyでリリースするビルドがそのままmilestone buildでもある場合があります。
このビルドは、「顧客(もしくはプロジェクトの利害関係者)にリリースするビルド」ととらえてもいいかもしれません。QAチームの外に漏れるビルドということです。また、エンドユーザーに評価してもらうための最初のマイルストーンビルドをalpha build、 その次のより完成度の高いマイルストーンビルドをbeta buildということもあります。
最新のビルドです。当然ですが、やはり文脈によって最新のビルドというのがどのビルドを指すのか違ってくるので、注意が必要です。単にlatestのビルドといえば大概最新のweekly buildのことですが、daily buildを立てているプロジェクトでは昨日のビルドのことでしょうし、最新のstableなビルドはどれだっけ? ということもあるでしょう。不具合があるかどうかをテストするには、最新のビルドで行うのが一番ですが、意味のあるテスト結果を残すにはきちんとビルド番号が管理されたビルドを使わなければなりません。このため、開発チーム内でテストを行う場合にはdaily/latest buildで、QAチームがテストを行う場合にはweekly buildで、ということも普通に行われます。
|
2/3
|
|
INDEX |
||
| 開発プロセス再入門(6) ビルドの位置付け |
||
| Page1 ◇ first build〜 |
||
| Page2 ◇ daily build〜 |
||
| Page3 ◇ stable build〜 |
||
| IT Architect 連載記事一覧 |
ホワイトペーパー(TechTargetジャパン)
|
|


