Rational Team Concertのある生活～チーム・メンバーの1日

3. ソース管理

RTCでは、「構成管理」は「ソース管理」という用語になります。RTCの「ソース管理」の最大の特徴は、チームの共用スペースである「ストリーム」に、各メンバーの管理する「リポジトリー・ワークスペース」を介して操作する点にあります^*1。

• [*1] 前回記事の【コラムC4】「ソース管理」（構成管理）の内部論理構造を参照

今回は、「ストリーム」「リポジトリー・ワークスペース」「ローカル・ワークスペース」とそれらの関係を理解したうえで、「ソース管理」にある重要な用語、機能について説明します。

3.1. コンポーネント

コンポーネントは、「（UnixやWindowsの木構造のファイル構造の）あるフォルダを基点（ルート）とするファイルおよびフォルダ（ディレクトリ）の集まり」です。「ルート」が異なるファイル群を1つのコンポーネントとすることはできません。1つ以上のコンポーネントの集合が「ストリーム」です。

3.2. 変更セット

変更セットは、「ある時点からある時点の、変更の差分の集まり」を意味します。具体的には、ある基準点（ベースラインやスナップショット）から、ソース・プログラムや文書ファイルなどに修正を加えると、変更の差分が発生します。それらの集まりを「変更セット」と呼びます。この（特に明示的に名称を付けることはありませんが）「変更セット」を「ローカル・ワークスペース」～「リポジトリー・ワークスペース」～「ストリーム」間、「提出」「受諾」などで操作することで、構成管理をするわけです。

ためしに、ローカルのEclipseプロジェクトの下にある、あるプログラムに修正を加えたとします。すると「保留中の変更」ウインドウに、それらが表示されます。

3.3. ベースライン、スナップショット

ベースラインは、言葉の通り、変更の集まりを管理するための、名前付けされたオブジェクトです（特別に「ラベル付けされたもの」だと考えると、理解しやすいです）。ベースラインは、コンポーネントに対して設定されます。最初にストリームを作るときに、最初に操作することになります。

RTCのベースラインの操作は、「ストリームを直接操作するのではなく（リポジトリー・ワークスペースの）「コンポーネント」に対して操作する」ので、注意が必要です。通常の変更セットを操作するように「提出」「受諾」を行うベースラインを反映させます。ベースラインの操作は、実行権限のあるユーザーに限られます。

一方、スナップショットは、（コンポーネント）ベースラインの集合として表される「ワークスペース」の構成を永続的に記録するための機能です。スナップショットの操作（作成）後、それをストリームに反映させるには、「提出」ではなく「プロモート」という操作を行います（結果を取り込むのは「受諾」で同じです）。

スナップショットは、ビルド・エンジンで（スナップショットが取られていない場合）自動的に作成されます。また、その場合は、自動的にそれに含まれる「コンポーネント」に、ベースラインが自動的に設定されます。

4. ビルド管理

RTCの「ビルド管理」では、「ビルド定義」に指定されたタイミング（例えば、月～金曜日の23:00 など）で、ビルドを実行します。ビルドには、以下の2種類があります。

チーム・ビルド

チームのビルドを支援する機能です。主に「ストリーム」上の「コンポーネント」のビルドを行います

プライベート・ビルド

個人のビルドを支援する機能です。主に「リポジトリー・ワークスペース」のビルドを行います

「チーム・ビルド」の手順は、以下の通りです。

1. ビルド定義
2. ビルド・エンジン
3. ビルド要求
4. ビルド結果

ここでは、「ビルド定義」「ビルド結果」を説明します。

4.1. ビルド定義

ここでは、RTCサーバーは、Windows Server の場合を例に説明を進めます。ビルドの命令は、バッチ・ファイルになります（図21）。このビルドの命令を、どのような場合（条件）になったら起動するか？を定義しているのが「ビルド定義」です（図21）。

画面を見ると、分かりやすい便利な設定ができることが分かります。

なお、ビルドを実行する「ビルド・サーバー」は、「RTCサーバー」である必要はありません。ただし、RTCサーバーを用いることによって、負荷を下げたり、異なるビルド環境を考慮しながらビルドに適した環境を使うといったことができるようになります。

4.2. ビルド結果と情報の追跡可能性

ビルドの管理は、特にチーム開発をしている時には重要です。必要な成果物は、共用エリアにアップロードされた場合（RTCでは「ストリーム」に「提出」された場合）に、ビルドを行うわけですが、以下のようなビルドの背景が管理されている必要があるわけです。

• それは、何時、ビルド実行されたのか？
• その結果は、正常に終了したのか？、それとも異常終了したのか？
• そもそも、それは、どんな理由の修正によりビルドを行うことになったのか？

このように情報の関係を追跡できること（追跡可能性）を「トレーサビリティ」と言います。RTC の機能概要を説明した図をもう一度見直してみましょう（図22）。

ここでは、説明が煩雑になることを避けるために「ソース管理」～「ビルド管理」との間のトレーサビリティだけを示していますが、実際に「ビルド管理」の画面をみると、「ワークアイテム」「スナップショット」などに、必要な要素にリンクが張られていて十分なトレーサビリティがあることが分かります（図23）。

少し詳しく「ビルド結果」の画面例を見てみましょう。まず、基本的なことですが、「ビルド結果」は、チームメンバーであれば、全員参照できます。これで、チーム内に情報の「壁」はなくなります。ビルドの「状況のトレンド」は、バーのような表示になっています。そのボックス1つが1つのビルド結果を表します。そのボックスをクリックすると、該当のビルド結果が表示されます。赤いボックスは、ビルドに失敗したことを表します。

「スナップショット」は、こうです。ビルドが行われた際に、まだスナップショットが取られていない場合には、システムが自動的に「スナップショット」を取得します。リンクをクリックして「スナップショット」を開くと、スナップショットに含まれる「コンポーネント」がリストアップされます。

「ワークアイテム」には、このビルドに関係するワークアイテムへのリンクがあります。このため、「このビルドは、どのような要求に基づく修正作業のビルドなのか？」といったことが、簡単かつ確実に分かります。

今までは、「構成管理」「変更管理」「ビルド管理」を、小規模で短期間の開発プロジェクトのために使うことは、その準備も含めて多大な手間がかかっていました。ところが、RTCは、これらの機能がオール・イン・ワンで備わっている製品であるため、"リンクをクリックする"という簡単な操作だけで、必要な機能が実現できます。さらに、利用者だけでなく、システム構築・運用側からも省力化されています。

5. まとめ

前回と今回の2回で、RTCの機能について、その操作画面例とあわせて紹介しました。

構成管理は、地味ですが、重要な仕事です。構成管理ソフトとしては、オープンソースにも優れたシステムはあります。ところが、オープンソースの場合、システムの維持や組み合わせ設定などが煩雑であったり、相応の力量のあるエンジニアが運用に関与したりと、コストが見えにくくなりがちです。

今後、プロジェクトは、開発だけでなく保守も重視する必要があります。過去の必要な資産を、目的とする作業のために適切に復元することや、開発・改良・修正したものをリリースしていくことが求められています。しかも、今まで以上に、迅速で、かつ新しい開発環境に適合したものが求められています。

RTCは、統合開発環境として、Eclipse、Visual Studio Plug-in、Webブラウザという3つのUI（ユーザー・インタフェース）をサポートしています。導入したユーザーから「安心して利用できる環境」として高い評価を得ています。

今回は、メンバーの視点から説明しました。

次回は、チームの視点から説明します。