前回の続きの前に、ちょっと寄り道
この原稿を書いているまさにこのタイミングで、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チームサーバーに返します。
では、環境の設定へと進みましょう。
作業の流れ
環境設定作業の流れを簡単に説明します。
- ビルド作業用のユーザーの定義
- ビルド用のAntスクリプトの作成
- ビルド定義の作成
- ビルド・エンジンの実行
- ビルド・リクエストの投入
- ビルド結果の確認
一般的な運用では、1）から4）までをリリースエンジニアやビルドエンジニアが行い、開発者は5）以降を日々行うという形になるでしょう。
では、順々に見ていきます。
1）ビルド作業のユーザーの定義
ビルド・エンジンは、Jazzチームサーバーのクライアントとして機能します。従って、サーバーへアクセスするためのユーザーIDとパスワード設定が必要です。さらに、このユーザーIDに対して、ビルド実行の権限を与える特殊なライセンスを割り当てる必要があります。この割り当て作業は、Jazzの管理ツールで行います。
Webブラウザを起動して、［https://{Jazzチームサーバー}:9443/jazz/admin］へ管理者IDでログインします。図2は［ユーザー管理］機能の画面です。［クライアント・アクセス・ライセンス］の項目で、「Rational Team Concert - Build System（xx個使用可能）」をチェックしていますが、これでビルド用のライセンスをユーザー「hana」に割り当てたことになります。
以降のステップで説明するビルド・エンジンの実行では、このユーザーID「hana」が使われます。
2）ビルド用のAntスクリプトの作成
Antのビルドスクリプト作成します。ここでは、Eclipse JDTの機能を利用しましょう。［Java パースペクティブ］の［パッケージエクスプローラー］で、プロジェクトを選択して右クリック、図3のコンテキストメニューが表示されます。
［エクスポート］を選択すると、図4のダイアログが表示されるので、［一般］-［Antビルド・ファイル］を選択して、［次へ］をクリックします。
この後、エクスポート先として、今回のプロジェクト「HelloJazzWorld」を指定してください。図5のようになればOKです。
ここで、「build.xml」のアイコンが黄色い四角で囲まれていますね？これは、作業者のリポジトリー・ワークスペースにはファイルが追加されたが、統合領域である「ストリーム」にはまだ反映されていない（＝ build.xmlが転送されていない）、ということを示します。［保留中の変更］ビューから、［提供］を指示して、「ストリーム」に反映させましょう（このあたりは前回とりあげました。おさらいをしておきましょう）。
3）ビルド定義の作成
いよいよ本題です。
ビルド定義では、次の項目を設定します。
- 利用するビルド・エンジン
- ビルド対象となるストリーム
- ビルド用のリポジトリー・ワークスペース
- リポジトリー・ワークスペースと連動するローカルの作業領域
さきほど、ビルド・エンジンがJazzチームサーバーのクライアントであることは説明しました。皆さんがお使いになるRTCクライアントと同じです。ストリーム、リポジトリー・ワークスペース、ローカルの作業領域等々、すべて皆さんがRTCクライアントをお使いになるときに指定するものばかりです。ビルド定義だからといって構える必要はありません。
［チーム成果物］ビューでツール表示を展開後、［ビルド］を選択し右クリックすると図6のようになります。
ここで、［新規ビルド定義］を選択すると、新規ビルドを作成するチーム・エリアを確認するダイアログが現れた後で、図7のダイアログが表示されます。
ここで、［Ant - Jazzビルド・エンジン］を選択します。
ビルド対象を管理しているSCMのエンジンとして、［Jazzソース管理］を指定します。
いくつかダイアログでパラメータの設定を問われますが、今日のところは全部チェックして進めましょう。最終的には、図9のような［ビルド定義］のビューが現れます。
チームでは複数のビルド定義を持つことができます。このビューでは、どこのチームで定義されたビルドか、このビルドで使うビルド・エンジンが何か、このビルド定義の識別用のIDは何かが提示されています。
さて、もう少し設定すべきものがあります。ビルドスケジュール、ビルドで利用するリポジトリー・ワークスペース、ビルドで利用するANTのスクリプトファイルが必要です。それらを順に指定していきましょう。
［ビルド定義］ビューの下にタブが並んでいます。［スケジュール］を選択すると、図10が表示されます。
継続的統合では統合ビルドを繰り返すことでチームのリズムを作ります。そのスケジュールをこのビューで設定します。次に、［Jazzソース管理］タブをクリックしてください。
図11のビューに変わります。
［ビルド・ワークスペース］-［ワークスペース］と、［ロード・オプション］-［ロード・ディレクトリー］の欄は空白になっていると思います。前者はビルド・エンジンが利用するリポジトリー・ワークスペース、後者はそれと連携するビルド・マシン側のローカルの作業領域です。前者では対象となるリポジトリー・ワークスペースを選択（あるいは新規に作成）して、リソースの元となるストリームを関連づけていきます。このあたりのステップは、RTCクライアントで皆さんがリポジトリー・ワークスペースを作るときと同じ手順で進みます。
ただし、この手順の途中で、図12のダイアログが出てくることがあります。
ビルド定義作業自体は、ビルド用のライセンスを割り当てられていない人もできますが、それを利用した日々のビルド作業は、ビルドライセンスが必要となります。同様に作業領域の所有者を合わせておく必要があります。
そこで所有者が合っていないと、この警告が表示されます。
所有者を変更するために、［ワークスペースを開く］を選択し、ワークスペースの所有者を変更しておきましょう。
次にAntのビルドスクリプトを指定します。図13をご覧ください。
前述したJDTを利用して作成したAntのファイルの場所を指定します。ビルド定義では、関連づけられたリポジトリー・ワークスペース（この例であれば、「HelloJazzWorld チーム ビルド ワークスペース」）から、ビルド・エンジンが稼働する作業領域（「fetched」）へとリソース（Eclipseプロジェクト「HelloJazzWorld」）をロードしてビルド作業を行います。このため、ビルド・ファイルの場所の表現は図に見られるように「fetched/HelloJazzWorld/build.xml」となります。
ここまでで、チームで共有するビルド定義の作成が終わりました。
開発者の日々の作業では、ビルド・システムに対して、ビルド作業を「リクエストする」ことで統合ビルドが進みます。ビルド・システム側は、先に起動して、リクエストが来るのを待っている必要があります。
4）ビルド・エンジンの実行
RTCに同梱されているビルド・エンジンは、次のコマンドで実行することができます。
cd {Jazzビルド・システムのインストールディレクトリ}\
jbe -repository {Jazzチーム・サーバーへのURL} -userId {ビルド権限を持ったユーザーID} -pass {パスワード} -engineId {ビルド・エンジン} -sleepTime {スリープ時間}
jbe -repository https://localhost:9443/jazz -userId hana -pass hana -engineId HelloJazzWorldBuild -sleepTime 3
RTCに同梱されているビルド・エンジンは、RTCサーバーへのURLを指定してそのリソースにアクセスします。指定例に見られるように、RTCサーバーと異なるマシン上で稼働していても問題ありません。例では、ビルド用のユーザーとしてhanaを割り当てています。前のセクションで触れたように、ビルド用のユーザーには、管理ツールからビルド・システム用のライセンスを割り当てておきます。-engineIdは、先ほどのビルド定義の際に定義した「ビルド・エンジン」のIDを指定します。設定に誤りがなければ、このままリクエスト待ちの状態に入ります。
ここまでできれば、開発者はビルド・リクエストをサーバーに投げることができます。
5）ビルド・リクエストの投入
立場を変えて、開発者の立場でビルド・リクエストを投げてみましょう。［チーム成果物］ビューでツリー表示を展開、ビルド定義を右クリックします。図15のコンテキストメニューが表示されますから、
ここから［ビルドの要求］を指定しましょう。
図16の［ビルドを要求］でリクエスト内容を確認したら、［実行依頼］をクリックしましょう。
ビルド・システム側がリクエストを受けて処理をすると、RTCクライアント側の［ビルド］ビューには、図17のようにリクエスト結果が表示されます。
結果を参照したい行をダブルクリックすると、図18のビルド結果を見ることができます。
RTCを使った開発作業では、「ソースコードの変更時にワークアイテムと関連づける」という日々の作業をこなすことによって、ビルド時にどのワークアイテムに対応したビルドかが、レポートに自動的に組み入れられます。
このビルドレポートの［コントリビューションの要約］のところに、［ワークアイテム］という項目があります。このリンクを順にたどっていくことで、対応したワークアイテムの内容、それに応じたソースコードの変更箇所まで知ることができます。
継続的統合環境で、チームの「今」を知る
統合プロセスを繰り返すことで、チームのリズムを作ることは、説明した通りです。RTCでは、いろいろな手段で統合のリズムを提示しています。リストアップしてみましょう。
ビルドの状況を履歴で見る
図19のビルド・レポートでは、個々のビルドの結果と共に、これまでのビルドの状況履歴を表示しています。［状況のトレンド］のところでは、成功したビルドは緑で塗りつぶされた四角い枠、失敗したビルドは赤く塗りつぶされた四角い枠として表示されます。上下を三角マークで挟まれた四角い枠が、今結果を表示しているビルドであることを表します。この四角い枠をダブルクリックすると、そのビルド結果が表示されます。
プロジェクトの初期は、コードの品質も安定していないし、1回の反復でチームがどの程度の作業が可能かというペースも見極められていないことが普通です。そのような時期は、「赤い四角枠」が並ぶことでしょう。これを、「緑の四角枠」が並ぶように、作業を分解して粒度を調整したり、ペア・プログラミングなどの品質向上対策を実行して、チームの開発ペースを作っていくのです。
［チーム・セントラル］で、チーム全体として何が起こっているか知る。
チームのメンバーが実施した作業は、イベントとしてすべて記録されています。チーム・メンバーがリクエストしたビルドもはじめ、今何が行われているかを把握することができます。
最後に
以上で、継続的統合環境の構築は終了です。最初のうちは、ビルドが予定通りできずに、ちょっといらいらするかもしれません。しかし、統合の成功・失敗ほど、プロジェクトの進行状況を見る上で明確な基準もありません。チームが安定したペースで作業できるようになるまで、頑張っていきましょう。
