以下に、ビルドのライフサイクルを示します。
開発中
担当者は開発者です。各開発者はこのビルドで達成しなければならないことや、ビルドを行う日を意識しながらソフトウェアを開発します。
ビルド
担当者はビルド担当者です。ビルド担当者は、ビルドの前に開発者にビルドを行うことを告知して、開発者全員の同意がえられたらビルド作業をおこないます。コンパイルエラーなどが出てビルドが通らなければ、開発者に修正を依頼し、期日までにビルドがリリースできるようにします。ビルドが終了したら、その旨を開発者に告知します。
テスト
担当者は開発者です。ビルド担当者からの告知を受けて、ソフトウェアをインストールし、テストをします。自分が追加したはずの新しい機能が正しく実装されているか、修正したはずの不具合が正しく修正されているかを確認するということです。リリースできると判断できれば、ビルド担当者にリリースの依頼をします。テストの結果、予定していたテストが実施できなくなるような不具合が見つかればビルドの状態を「開発中」に戻します。
リリース
担当者はビルド担当者です。開発者からの告知を受けて、リリースの準備（リリースノートの記述、取りまとめ）をします。成果物をしかるべき場所に保存し、リリースを告知します。
ビルドは、以下の要件を満たしていなければなりません。
- リリースされる範囲が明確であること
- バージョン番号が付加されていること
- リリースノートが添付されていること
- インストーラが添付されていること
リリースされる範囲が明確であること
担当者は開発者です。各開発者はこのビルドで達成しなければならないことや、ビルドを行う日を意識しながらソフトウェアを開発します。
バージョン番号が付加されていること
バージョン番号が付加されているということは、このソフトウェアのユーザーが、いまどのビルドを使っているのかを確認する手段が用意されているということです。リリースノートにバージョン番号が書いてあるだけでは、バージョン番号が付加されているとはいえません。最初のバージョン番号をリソースという形でプログラム中に埋め込んでおき、これを確認する手段を用意しておくことをお勧めします。
リリースノートが添付されていること
リリースノートは、各ビルドのリリースに際して添付される文書です。リリースに含まれる成果物、リリースによって実現する内容、制限事項等を明記することで、後で追跡できるようになります。
インストーラが添付されていること
ビルドは可能な限り、エンドユーザーにリリースするのと同じ状態にしなければなりません。ユーザーが正しくソフトウェアをインストールできるかどうかも、テストの対象とすべきだからです。なるべく早い時期のビルドから、インストーラを準備するようにしましょう。
ビルド環境は、リリースを繰り返すたびに少しずつ洗練され、自動化された部分やビルドすべきモジュールなども増えていくはずです。それにつれて、ビルドの手順も変わってきます。ビルド手順書を用意し、最新の状態にメンテナンスすることをお勧めします。
2 / 2
