ソフトウェア構成管理の目的はなに？構成管理の目的は、構成を再現ですが、そのの目印が必要となります。目印とは何なのでしょうか。
構成管理の肝
自分達がどんな構成を必要としているかについて自覚しておく必要があり、どの時点におけるシステムの構成を再現したいのかが分かった上で、初めてどのバージョンを使えば良いかが必要になる。
ベースラインとは？
バグ改修の話であれば、直近にリリースされた構成であり、必要な構成は、ソースコードだけではなく、上流工程の成果である要件や、設計書、設計モデルも変更される可能性がありますね。
バグ改修を行う場合には、その時点で再現したい、もしくは将来的に再現したくなるであろう構成、つまりベースラインが3つ生じると考えられます。
- バグを発見したベースライン
- バグを改修する対象となるベースライン
- バグを改修し、反映したベースライン
3つのベースラインを認識して初めて、バグの原因を解明し、適切なソースコードを取得し、正しく改修をおこなう、という所定のプロセスを全うすることができます。
反対に、もしベースラインを把握できていないまま作業を行えば、バグの再発や新機能の消失といったデグレードを引き起こすことになるかもしれません。
変更セット
ある作業と、その作業によって作成（もしくは変更）された成果物のバージョンをセットとして識別する単位です。
例えば、バグ改修であれば、バグ改修という作業と、そのバグ改修によって修正されたソースコードのバージョン（これは通常複数個になります）のセットということになります。
変更セットで複雑なソースコードの関係をまとめあげ、さらにベースラインで変更セットの関係をまとめあげているわけです。
ひとつのベースラインに、どのような内容が反映されているのかが明確になります。
言いかえれば「どのベースラインを再現すべきか」の基準がはっきりするわけですね。
ベースラインと変更セットをキッチリ管理できれば、複雑な構成に悩まされることもなさそうです。
ビルド管理とは
ビルドはソースコードの内容などが確定した状態で行うものです。特に意味も無くビルドしてみた、などというケースはあまりないでしょう。
例えば、「機能追加プロジェクトで実装が完了した時点」などで行うはずです。すると、ビルドは将来的に再現したくなる可能性がありますね。
- 実施したテストケース
- 実施したテストの結果
- 発見したバグや仕様変更
- ビルドのステータス
バグが修正されているか、機能が動作するのかといった確認を行うため、ビルド成果物には必ずテストが実施されます。その際にもちいたテストケースやテスト結果は空名図保管しておく必要があります。
また、テストの結果として、バグや仕様とのミスマッチなどが発見される場合もあるでしょう（前回お話した作業管理との関連がここにあらわれてきますね）。
さらに、ビルドのステータスについて把握しておくことも大変重要です。一般的なビルドのステータスの例を挙げてみましょう。
ビルドするに当たり、考えなければならないこと
どのソースコード、設定ファイル（リビジョンを含めて）を構成要素とすればよいのかを決定することです。
構成管理台帳を作成し、人の手で管理することもできますが手間や正確性を期すために構成管理ツールと連携を考えた方がよいでしょう。
また、ビルドした場合にどの構成要素を利用したかを明確にするためにビルドした要素を1つのバージョンとします。
CVSを利用するのであれば、これらの構成要素にビルドIDのタグを付けます。
適切な構成要素の組み合わせ（図2のピンクの組み合わせ）を構成管理ツールからチェックアウトし、ビルドする。ビルドした構成要素の組み合わせ（図2のピンクの組み合わせ）に対して、構成管理ツール上でバージョン付けを行うという手順で連携をします。
ライブラリ管理とは？
プロジェクトで利用しているライブラリ（商用、自社、オープンソース）のバージョンの違いによるインターフェイスの不整合が起こることがあります。このことによってコンパイルができなかったり、プログラムの書き直しが必要になったりします。
特に、オープンソースのライブラリを利用している場合に多くこの問題が発生します。「環境設定定義書」などの文書によってライブラリのバージョンは指定してもプログラマが独自にダウンロードしたり、外部サイトでは指定したバージョンがダウンロードできなくなったりしてこの不整合が発生します。
複数のプロジェクトで同じライブラリを使っている
ライブラリの更新の作業やスペースに関して「ムダ」ができてしまう可能性があります。
利用するライブラリに関しては複数のプロジェクトで1つのリポジトリに格納して、ビルドに利用する方法も考えられます。
この方法ではライブラリをどう格納するかを決定する手間はありますが、命名規則などで複数のバージョンを同居させることでライブラリ更新の作業も簡単に行うことができます。
何らかの方法によってライブラリを管理する必要があります。後者の方法でライブラリを管理するツールとしてApache Mavenがあります。Mavenについては、後ほど説明します。
MAVENでのライブラリ管理
MavenでもAntと同様に以下のような設定ファイル（project.xml）を作成します。作業は後で説明する「ゴール」によって定義され、ユーザーが定義する必要はありません。
Mavenの設定ファイルではフォルダ構成や組織、プロジェクトの情報、構成管理ツールのアクセス方法などを定義することになります。
ライブラリ管理の方法のうち、リポジトリによる共有の方法をMavenは実現します。Mavenをインストールするとインストールしたユーザーのホームディレクトリに.mavenというフォルダが作成され、このフォルダ以下がリポジトリとなります。このフォルダにライブラリを命名規則に従って格納し、共有します。
