目次


はじめて使う Jazz

第 3 回 ソースコード管理

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: はじめて使う Jazz

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:はじめて使う Jazz

このシリーズの続きに乞うご期待。

今回は「継続的統合」

さて、3回目のテーマは、ソースコード管理とビルド管理です。RTCにはSubversionと同種のソースコード管理に加え、ビルド管理の仕組みも組み込まれています。それらを組み合わせて、アジャイル開発で言うところの「継続的統合(CI:Continuous Integration)」環境を組み上げよう! というのが、今回のお題です。

RTCのソースコード管理には、アジャイル開発を意識した独特の機能が組み込まれています。このことが、CVSやSubversionに慣れた開発者にとっては、分かりづらいと思われてしまうのも事実です。

そこで今回は、

  • まずは、ソースコード管理周りの基本を理解する。
  • ビルドものぞいてみる
  • アジャイルっぽくCIしてみる

と、3段階で話を進めていこうと思います。

マニアックな深みにはまらないよう注意しつつ、話を進めましょう。

まずはJazzのソースコード管理の基本を理解する

本シリーズの第1回で、既にプロジェクトをソースコード管理に登録するまでの手順を説明しました。ちょっと流れをおさらいして見ましょう。忘れてしまった方は、第1回目をブラウザの別ウィンドウで見つつ読み進めてください。

  • ステップ0:
    普通にEclipseのプロジェクトを作る(連載では、「HelloJazzWorldプロジェクト」を作りました)。
  • ステップ1:
    Eclipseの[プロジェクトの共用]機能を呼び出し、リポジトリー・タイプとして[Jazzソース管理]を選択する。
  • ステップ2:
    「コンポーネント」を指定します(図1)。
図1
図1
図1

ステップ1までは、Subversionを利用した場合と同じ流れなので違和感がないと思いますが、ステップ2に入ると、いきなり「じゃず・わーるど」に突入しています。

「既存リポジトリー・ワークスペース内のコンポーネントの選択」という文を理解するところから始めましょう。

管理単位は「コンポーネント」

Jazzのソースコード管理では、他のソースコード管理システムと同様に、個々のファイルあるいはディレクトリを対象に版管理が行われます。チェックアウト/チェックインを繰り返すと、リポジトリ内で版番号が一つずつ増えるところも同じです。RTCのソースコード管理では、その上位に「コンポーネント」という考え方を導入しています。早速ですから、コンポーネントの中身は何かを見てみましょう。RTCのサーバーを起動して、クライアントから「taro」でリポジトリにログインします(忘れてしまった方は、本シリーズの1回目を参照してください)。

[チーム成果物]ビュー-[マイ・リポジトリー・ワークスペース]とツリーを開き、コンポーネント[HelloJazzWorldチームデフォルト・コンポーネント]を右クリックするとコンテキストメニューが表示されます(図2)。

図2
図2
図2

ここから、[リポジトリー・ファイルの表示]を選択すると、[リポジトリー・ファイル]ビューが開きます(図3)。

図3
図3
図3

Eclipseのプロジェクト以下の構造がそのまま入っていますね。コンポーネントとは、その内部にEclipseのプロジェクトを格納した「論理的な入れ物」です。例ではプロジェクト一つだけですが、複数のプロジェクトを格納することもできます。Eclipseの[プロジェクトの共用]機能で、対象となるEclipseプロジェクトをコンポーネントに関係づけるのは、本シリーズの初回でご覧いただいたとおりです。

ちなみに、新しくRTCのプロジェクトを作成すると、次のものが自動的に作成されます。

  • プロジェクト名と同じ名称を持ったチームエリアが一つ
  • 「プロジェクト名+『チームリポジトリー・ワークスペース』」という名称を持ったリポジトリー・ワークスペース
  • 「プロジェクト名+『デフォルト・コンポーネント』」という名称を持ったコンポーネント

日々の開発作業では、個々のファイルをチェックイン/チェックアウトして編集します。コンポーネントを使うのは関連するリソースをひとまとめにして行う操作、例えば他の開発者との共有や、「ベースライン」をつけて管理するなどです。コンポーネントにベースラインを宣言してみましょう。

[チーム成果物]ビューの[マイ・リポジトリー・ワークスペース]のツリーを開いてみると、「HelloJazzWorldチームデフォルト・コンポーネント(1.初期ベースライン)」と表記されています(図4)。

図4
図4
図4

この「(1:初期ベースライン)」がベースライン名称です。ここでコンポーネントを選択して右クリックし、[新規]-[ベースライン]を選択します(図5)。

図5
図5
図5

ダイアログでベースライン名称を入力し、[OK]ボタンをクリックするとベースライン名を変更できます(図6)。

図6
図6
図6

以上で、ベースライン宣言の終了です。「(1.初期ベースライン)」から「(2.単体テスト終了)」に変わっているのが、分かります(図7)。

図7
図7
図7

RTCのソースコード管理はコンポーネントという概念を導入することで、次の2つのことを達成します。

その1:成果物の集合体をコンポーネントという論理的な入れ物で管理することによって、必要な「ひとかたまり」を明確に定義・管理することができる。例えば、一つのコンポーネントの中に、関連するソースコード、UMLによる設計モデル、JUnitプロジェクト等複数のEclipseプロジェクトを、ひとまとめに管理・操作できる。

その2:コンポーネントは言い換えれば、「チームごとの仕事の分担」「チームの成果物」である。例えば、「単体テスト終了」「マイルストーン1」「バージョン 1」などの開発途中の大きな節目にベースラインを宣言することで、チームの作業進捗が明確になり、多くのチームが共同開発する場合に、お互いの作業状況をより把握しやすくなる。

RTCでは、「プロジェクトは、コンポーネント化されたソフトウェアを、複数のチームで開発する」という開発スタイルを想定しており、それに合わせた管理のやりやすさを、コンポーネントという概念でサポートしているのです。

間を取り持つ作業領域:「リポジトリー・ワークスペース」

次はリポジトリー・ワークスペースです。図8は、RTCの作業領域の考え方を簡潔に表現したものです。

図8
図8
図8

RTCでは次の3つの作業領域を想定しています。

3つの作業領域
名前説明
ストリームサーバー側のリポジトリ内に存在して、チームのリソースを「統合する」ための領域。チームのメンバーは各自の作業を完了すると、決められたストリームに成果物を登録することで、他のメンバーと共有できます。
リポジトリー・ワークスペースストリームと、(クライアント側の)Eclipseワークスペースの中間、サーバー側に設けられる領域です。ストリームから必要なリソースをリポジトリー・ワークスペースに引き出して、そこからEclipseワークスペースにロードします。
Eclipseワークスペース普通のEclipseで利用するワークスペースです。

この3つの作業領域がどのように連携(あるいは同期)するのかは初めての方には、なかなか分かりづらいかと思います。ここでは少々トリッキーな操作ではありますが、「Taroが2つのリポジトリー・ワークスペースを持った場合に、どのように振舞うか」を通して、理解を深めていきましょう。

早速、リポジトリー・ワークスペースをもう一つ作りましょう。

[チーム成果物]ビュー-[マイ・リポジトリー・ワークスペース]を右クリック、[新規]メニュー項目から[リポジトリー・ワークスペース]を選択します(図9)。

図9
図9
図9

ここで、[新規リポジトリー・ワークスペース]ダイアログが表示されます(図10)。

図10
図10
図10

このダイアログでは、今から作る新しいリポジトリー・ワークスペースと、「HelloJazzWorldチームストリーム(※HelloJazzWorldプロジェクト作成時に自動的に作られたものです)」とを関係づけています。今後、このリポジトリー・ワークスペースで行われた作業結果は、HelloJazzWorldチームストリームに統合されていきます。

ここでは、ストリーム一つだけで話しをしていますから、わざわざ関係づけるのは余計な手間のように思えます。RTCでは、チームは用途別に複数のストリームを持つことができます。さらに、メンバーは複数のリポジトリー・ワークスペースを持つことができます。リポジトリー・ワークスペースとストリームとの関係づけは、さまざまな組み合わせがありうるので、この関係づけ作業が必要になるのです。ちなみに、この関係づけのことを、「じゃず・わーるど」では「フロー」と呼びます。リポジトリー・ワークスペースでの作業の結果を、ストリームに「流し込む」――そんなニュアンスです。

さて、操作を続けましょう。

新しく作ったリポジトリー・ワークスペース(例では、「Taro'sリポジトリー・ワークスペース2」と名付けました)で操作するコンポーネントを指定する必要があります(図11)。

図11
図11
図11

ここで、コンポーネントのベースライン名称に注意してください。「(1.初期ベースライン)」になっていますね? さきほど、「(2.単体テスト終了)」にしたはずですが、それはどこにいったのでしょうか?……ここに、作業領域間の連携を理解する鍵があります。これを解き明かすために、もう少し作業を先に進めましょう。

次に表示される[リポジトリー・ワークスペースのロード]ダイアログで[Eclipseプロジェクトの検索およびロード]を選択しましょう。途中、既存のプロジェクトを置き換えるかどうか聞いてきますが、気にせず先に進みましょう! 最終的には、図12のようになると思います。

図12
図12
図12

Eclipseの右下、たくさんビューが並んでいるところから[保留中の変更]ビューを選択してください。2つのリポジトリー・ワークスペース(例では、「HelloJazzWorldチームストリームワークスペース」と「Taro's リポジトリー・ワークスペース2」)ができています。これは、現在Eclipseのクライアントがこの2つのリポジトリー・ワークスペースに関係づけられていることを示します。

ここで注意すべきは、おのおののリポジトリー・ワークスペースに見られるコンポーネントは、ベースラインが異なるという点です。「Taro's リポジトリー・ワークスペース2」内のコンポーネントは直前の関係づけ操作に見られたように、「(1.初期ベースライン)」というベースラインがつけられています。

図13をご覧ください。

図13
図13
図13

ベースライン「(2.単体テスト終了)」宣言の際に利用していたのは、HelloJazzWorldチームリポジトリー・ワークスペースでした。「ベースラインが宣言された」というリソースに対する変更指示もHelloJazzWorldチームリポジトリー・ワークスペースに記録されます。しかし、まだこのタイミングでは、チームの統合領域であるストリームには伝わっていません。ストリーム内のコンポーネントのベースラインは、まだ 「(1.初期ベースライン)」のままです。この状態で新しいリポジトリー・ワークスペース「Taro's リポジトリー・ワークスペース2」を作り、そこを介してストリームからコンポーネントをロードしています。

[保留中の変更]ビューで、「2.単体テスト終了」が[発信]というフォルダーに位置づけられているのは、「『ベースライン(2.単体テスト終了)宣言』という変更指示が、まだチーム全体の統合領域であるストリームに適用されていません。適用してください」ということを意味します。ここで、右クリックして[提出]を選択すると(図14)、

図14
図14
図14

[保留中の変更]ビューは図15のように変わります。

図15
図15
図15

今度は新しく作ったリポジトリー・ワークスペースに、[着信]というフォルダーができ、その中に「(2.単体テスト終了)」への変更情報が格納されます。この様子を説明するのが、図16です。

図16
図16
図16

[提出]処理によって、ストリーム内のコンポーネントのベースラインも、「(2.単体テスト終了)」になりました。RTCはストリームに変更が発生すると、そのストリームに関連づけられているリポジトリー・ワークスペースに対して、変更が発生したことを通知します。それを[着信]としてみることができます。各メンバーは作業をしている最中ですから、強制的に変更内容を適用することは好ましくありません。各メンバーは、図17のように[受諾]処理を行うと、

図17
図17
図17

自身のリポジトリー・ワークスペース(とそれに関連づけられているEclipseワークスペース)に変更を適用することができます。

複数の開発者が設定したリポジトリー・ワークスペースとストリームとの関係をグラフ化することができます。それがフロー・ダイアグラムです。図9はリポジトリー・ワークスペースの新規作成の説明でみた画面イメージですが、このメニューにある[フロー・ダイアグラム]を選択します。

図18 は、jiroでログインしたRTCからフロー・ダイアグラムを作成した結果です。

図18
図18
図18

アジャイル開発のための便利なお砂箱、「リポジトリー・ワークスペース」

一見すると、リポジトリー・ワークスペースは、「一手間増やしている」ように見えるのではないでしょうか? リポジトリー・ワークスペースは、アジャイル開発を強く意識した仕組みです。アジャイル開発を、ソースコード管理という視点から見ると、次のような特徴があります。

  • 必要最小限のドキュメントで、後は「ソースコードで会話する」というアプローチは、さまざまなアルゴリズムを設計書ではなく、コードを実装し動かしながら検討していくことにつながる。開発者は、場合によっては複数の異なるアルゴリズム、異なる環境を同時期に比較・検討を(ある時はトライ&エラーで)進めていく。また他の地域にいる開発者と意見交換する場合にも、これら「未完成のコード」を共有できる必要があるが、その場合にも、チームの統合領域を損なうことは避けたい。
  • ペアプログラミングでは、1台のマシン環境を共有しコードやベータ版で相談する。オフショアなどの分散開発で同様な協調作業を実現しようとすると、単にコードの断片をやりとりするだけでは、再現環境を構築する手間が頻繁に発生する。稼働環境そのものが共有できる仕組みが必要となる。
  • 他のメンバーの仕事をカバーする場合にも、迅速に作業環境を引き継げる仕組みがないと、自分のこれまでの作業環境を一時的にバックアップできる仕組みが必要。

リポジトリー・ワークスペースという作業領域をサーバー側に持たせることによって、上記の課題を解決します。いくつか例を挙げてみましょう。

  • 開発者は、複数のリポジトリー・ワークスペースを簡単に作成することができます。おのおののリポジトリー・ワークスペースで異なるアルゴリズムを検討し、ベストなものだけを統合領域に登録することができます。開発者は検討の過程で必要なリポジトリー・ワークスペースからコンポーネントを「ロード」してEclipseワークスペースを置き換えたり、Eclipseワークスペースを「アンロード」して退避できます。これにより迅速に作業領域を切り替えることができます。
  • 開発者は、リポジトリー・ワークスペースを他の開発者に公開することができます。これにより検討中のアルゴリズムの評価や検討を、ネットワークを介した別の開発拠点にいる開発者と実施できます。
  • リポジトリー・ワークスペースのスナップショット(コピー)をとって、他の開発者と共有して作業を分担したり、そのスナップショットから新しいリポジトリー・ワークスペースを作ったりすることで、環境構築の手間を劇的に削減することができます。

「統合領域を『汚すことなく』、自由に環境を変えたり、遠隔地にいる他の開発者と安全にリソースを共有できる」という点で、リポジトリー・ワークスペースのことを、「サーバー側のお砂箱(Server-side Sandbox)」と呼ぶこともあります。

次はビルド管理…

…と思ったら、「今回は結構ヘビーだな」というコメントが社内であがりました。ということで、今回はこの辺でいったん終わりとしましょう。次回はビルド管理、そして憧れのCI環境へと邁進していきます。それまでに、ぜひ実際にリポジトリー・ワークスペースで遊んでみてください!

では次回!


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Rational
ArticleID=378589
ArticleTitle=はじめて使う Jazz: 第 3 回 ソースコード管理
publish-date=04032009