前回の続きの前に、ちょっと寄り道
この原稿を書いているまさにこのタイミングで、Jazz.netのほうから、多言語対応の正式版（バージョン1.0.1.1）がリリースされました。この連載を読みつつ実際にRational Team Concert（以降、RTC）をさわっている皆さんの中には、新しいバージョンが出るたびに、次々と置き換えてきた方がいらっしゃるかもしれません（手間をかけていただいてありがとうございます！）。そんなときに気になるのは、これまで蓄積してきたリポジトリーのデータ。本題の継続的統合環境の構築に入る前に、リポジトリーを移行する手段を紹介しておこうと思います。
RTCでの環境を維持するために、次の2つのディレクトリとファイルが必要です。
- {RTCインストールディレクトリ}\server\repositoryDB
- {RTCインストールディレクトリ}\server\tomcat\conf\tomcat-users.xml
――ソースコードやワークアイテム等々が格納されているリポジトリーそのもの
――ユーザー管理情報が入っているファイル
本連載で紹介しているRTCのExpress-Cというエディションでは、リポジトリー用のデータベース・エンジンとしてDerby、アプリケーションサーバーとしてTomcatを使っています。リポジトリーを移行するには、上記2つのディレクトリとファイルをファイルコピーするだけでOKです。より上位のエディションでは、Derby/Tomcat以外にも、商用のリレーショナルDBやアプリケーションサーバーを使えますが、その場合には単純なファイルコピーでは移行できません。専用のコマンドラインツールが提供されますが、詳細はマニュアルをご覧ください。
前回は、RTCのソースコード管理の概念を説明しました。リポジトリー・ワークスペースという「サーバー側のお砂箱」を設けることによって、チームメンバーが共有している統合領域（ストリーム）のコードを保護しつつも、開発者がさまざまなアイディアを自由に実装・検証し、さらにそれらをネットワーク越しにいる開発者同士が共有できる……これによって、あたかも同じ場所で一緒に作業しているかのような環境を作っているのです。
それでは、ビルド環境の構築の話に進みましょう。
RTCによる継続的統合の流れを理解する
開発者は自分の作業環境の中でコードをビルドし動きを確認します。これに加えて、継続的統合の考え方では、チームメンバーのリソースを収集し全体をビルドするまでの一連のプロセスを、定期的にかつ頻繁に行います。場合によっては、途中のステップに単体テストやコード分析を組み入れて、品質検証まで含めた統合プロセスとすることもあります。
統合プロセスを繰り返す行う理由としては以下のものを挙げることができます。
- 分散して開発しているモジュール群の統合リスクを、より早いタイミングで発見する。
- ビルドや統合の状況を頻繁に可視化することで、品質の状況を把握する。
- メンバー全員で共有することで、ビルドに対するチームの集中力を高める。
- 定期的に実行することで、チーム全体の作業の「リズム」を作る。
日々の開発作業の中で、RTCを使った継続的な統合作業の流れを、図1によって理解しておきましょう。
中心的な役割を果たすのは、「ビルド・エンジン」です。ビルド・エンジンは、ビルド対象となるリソースの収集とビルドの実行（Antなどの呼び出し）、結果の取り込みまでの一連のプロセスを実行します。
どのコンポーネントをどのビルド・エンジンでどんな条件でビルドするのか、その指示を定義したのが「ビルド定義」です。1つのプロジェクトでも、「開発チーム向け」「保守チーム向け」というように、複数のビルド定義が必要になります。開発者は、日々の開発では、このビルド定義を基に、実際のビルドの指示をJazzチームサーバーに投入します。これを「ビルド・リクエスト」と呼びます。ビルド・リクエストは、Jazzチームサーバー内のキューに処理待ち状態に入ります。Jazzビルド・エンジンがそれを順々に処理して、結果のログをJazzチームサーバーに返します。
では、環境の設定へと進みましょう。
