はじめに
前回は、ソフトウェア構成管理を実践するための現実的なアプローチ方法について述べました。
さて、本来の目標である「目的に応じて、必要な構成を任意に再現する」ためには、自分達がどんな構成を必要としているかについて自覚しておく必要があります。どの時点におけるシステムの構成を再現したいのかが分かった上で、初めてどのバージョンを使えば良いかという話になるのですね。
ソフトウェア構成管理においては、構成の識別について、「ベースライン」と「ビルド管理」という考え方でまとめています。今回はこの2つの概念について解説します。これらは、開発プロジェクトでの「ブランチ戦略」にも関わってくる重要な概念です。
ベースラインとは
さて、再現したい構成とは何を指すのでしょうか？ 前回のようなバグ改修の話であれば、直近にリリースされた構成などがそれにあたるでしょう。もちろん、必要な構成は、ソースコードだけではありません。上流工程の成果である要件や、設計書、設計モデルも変更される可能性がありますね。
開発を開始するに当たっては、自分達がどの構成に対して作業を行うべきかを把握できている必要があるわけです。
さて、「再現したい構成」は、開発のあらゆる工程において現れることでしょう。ソースコードの改修というレベルから、各工程間での作業の引き継ぎ（例えば、ビルド工程からテスト工程への引継ぎなど）というレベルまで、そのシチュエーションは多岐に渡ります。ここでは、将来的に再現したくなる可能性がある構成を「ベースライン」と呼びましょう。
ビルド成果物≒ベースライン
なお、開発工程の中でも特に実装工程を完了し、ビルド成果物が作成された後は、 ベースライン≒ビルドと考えるのが一般的です。ビルドはソースコードの内容などが確定した状態で行うものです。特に意味も無くビルドしてみた、などというケースはあまりないでしょう。例えば、「機能追加プロジェクトで実装が完了した時点」などで行うはずです。すると、ビルドは将来的に再現したくなる可能性がありますね。
ここでは、単純化するため「継続的インテグレーション（常時結合）については、触れないことにします。継続的インテグレーションを実践する場合は、より頻繁にビルドを行うことになります。この場合もベースラインとビルドの識別と管理は、同様に重要な概念となります。
ビルドを行う際は、ビルドスクリプトを使用することが一般的ですから、どのバージョンのどのソースコードを使っているかを特定することも簡単です。そして、それらのソースコードに関連した設計書や設計モデル、要件も含まれています。まさにベースラインですね。
ここで述べたベースラインの識別や管理に関する考え方は、第1回で説明したソフトウェア構成管理の要素のひとつである「ビルド管理」に含まれるものです。
