SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

渋谷テクニカルナイト講師陣が語る新技術動向(AD)

はじめて使うJazz (4)
― ビルド環境の構築

渋谷テクニカルナイト講師陣が語る新技術動向 第6回

  • X ポスト
  • このエントリーをはてなブックマークに追加

 前回は、Rational Team Concertのソースコード管理の概念を説明しました。今回は、前回の流れを引き継いでビルド環境の構築手順を紹介し、「継続的統合(CI:Continuous Integration)」環境を組み上げます。

  • X ポスト
  • このエントリーをはてなブックマークに追加

前回の続きの前に、ちょっと寄り道

 この原稿を書いているまさにこのタイミングで、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によって理解しておきましょう。

図1
図1

 中心的な役割を果たすのは、「ビルド・エンジン」です。ビルド・エンジンは、ビルド対象となるリソースの収集とビルドの実行(Antなどの呼び出し)、結果の取り込みまでの一連のプロセスを実行します。

 どのコンポーネントをどのビルド・エンジンでどんな条件でビルドするのか、その指示を定義したのが「ビルド定義」です。1つのプロジェクトでも、「開発チーム向け」「保守チーム向け」というように、複数のビルド定義が必要になります。開発者は、日々の開発では、このビルド定義を基に、実際のビルドの指示をJazzチームサーバーに投入します。これを「ビルド・リクエスト」と呼びます。ビルド・リクエストは、Jazzチームサーバー内のキューに処理待ち状態に入ります。Jazzビルド・エンジンがそれを順々に処理して、結果のログをJazzチームサーバーに返します。

 では、環境の設定へと進みましょう。

次のページ
作業の流れ

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
渋谷テクニカルナイト講師陣が語る新技術動向連載記事一覧

もっと読む

この記事の著者

藤井 智弘(フジイ トモヒロ)

日本アイビーエム株式会社 ソフトウェア開発研究所 Rationalエマージング・ビジネス・サービス。ソフト開発ってホントはもっとおもしろかったはず!という思いのもとで、”管理管理!”でも”開発者の自由!”でもなく、その程よいバランスこそが解と、啓蒙活動...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/3666 2009/03/23 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング