...

と による チーム開発ガイド Rational Application Developer

by user

on
Category: Documents
138

views

Report

Comments

Transcript

と による チーム開発ガイド Rational Application Developer
®
IBM Software Group
Rational Application Developer と Rational ClearCaseによる
チーム開発ガイド
Ver 1.0
2005年9月
日本アイ・ビー・エム株式会社
Rational Technical Sales & Service
© 2006 IBM Corporation
© 2005 IBM Corporation
SCM03
本資料の目的
ƒ 本資料は、IBM Rational ClearCase(以降、ClearCase)と、IBM Rational
Application Developer for WebSphere Software (以降、RAD)を利用し、チーム
で、J2EEアプリケーションを開発する際の考慮点をまとめたものです。
ƒ Rational ClearCase SCM Adapterを利用した、ClearCaseとの接続を前提としてい
ます。ClearCase Remote Client 固有の設定については、取り扱っておりません。
ƒ 本資料は、ClearCase、Eclipse、J2EEアプリケーション開発に関する基本知識、経
験を有している方を、対象としております。
注意点
ƒ この資料は日本アイ・ビー・エム株式会社の正式なレビューを受けておりません
ƒ 資料の内容には正確を期するよう注意しておりますが、この資料の内容は2005年9
月現在の情報であり、製品の新しいリリースなどによって動作、仕様が変わる可能
性がありますのでご注意ください
商標について
ƒ IBM、Rational Application Developer for WebSphere Software、Rational Clear
Case は、IBM Corporation の商標です。
ƒ Java およびすべての Java 関連の商標およびロゴは、Sun Microsystems, Inc. の
米国およびその他の国における商標または登録商標です。
ƒ Microsoft、Windows、Windows NT および Windows ロゴは、Microsoft
Corporation の米国およびその他の国における商標です。
ƒ 他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。
目次
ƒ 構成管理対象の決定
ƒ 概念のマッピング
構成管理対象とするファイル
ƒ 動的ビューにおける考慮事項
メタデータの管理方針
ƒ 非接続モードでの作業フロー
ƒ 開発環境の標準化
ワークスペースの標準名
ワークスペースのショートカット
環境設定の共有
外部JARファイルの共有
ClearCase チーム設定
RAD側の設定
構成管理対象の決定(構成管理対象とするファイル ①)
ソースとビルドを再現するためには、
以下のファイルについてフォルダー構成も含めて整合性を取って管理することが必要です。
・Javaソース
・.sqlj
・JSP/HTML/images
・EJBデプロイメント・ディスクリプター
ejb-jar.xml ( トランザクション属性) ibm-ejb-ext.xmi (分離レベル) , ibm-ejb-jar-bnd.xmi (JNDI名)
・WEBデプロイメント・ディスクリプター
web.xml , ibm-web-bnd.xmi, ibm-web-ext.xmi
・アプリケーション・デプロイメント・ディスクリプター application.xml
・ユーザー・プロパティなど
RADプロジェクト情報のクラスパス設定についても管理することを推奨します。
複数メンバーでの共用やビルド環境の再現にも有用です。
・classpath, project, serverprifrence, websetting, modulemaps
構成管理対象の決定(構成管理対象とするファイル ②)
その他、次のようなものを対象とすることが可能です。
・テスト用データ
・設計書などのドキュメント(クラス図など)
・データベースのDDL
管理対象から外すべきもの。
(マスターとしてのソースから生成されるものは管理対象から外します。)
・.class
・EJBのstub,tieなど
・インフラ提供プロジェクト バージョン管理対象としません。
・設定は、[ウィンドウ]-[設定]-[チーム]-[無視するリソース]にて。
※注意点
管理するリソースのタイプの指定に気をつけてください。マージが必要なものは ASCII とします。
・.sqlj .xmi, .MF ASCII
・設定は[ウィンドウ]-[設定]-[チーム]-[ファイル・コンテンツ] にて。
構成管理対象の決定(メタデータの管理方針)
ƒ デプロイメント・ディスクリプタのマージは避けましょう
ファイルそのもののマージは可能ですが、XMLのコンテキストは、
変更点を理解するのが難しいです
メタデータファイルのようにマージできないものに関しては、
ClearCase のトリガーを使用し、並行開発することが可能です
ƒ メタデータファイルはちゃんとバージョン管理しましょう
サーバー構成のファイルはソース管理に追加してはいけません
(この設定は、個々の開発者によって異なる可能性があるため)
.classpathと.projectファイルはソース管理に追加しましょう
クラスパスが一致していることを確認しましょう
(クラスパスは、インテグレーションストリームの中以外では、変更さ
れてはいけません)
開発環境の標準化
ƒ 可能な限りRAD ワークスペースは標準化する必要があります。
ƒ これには二つの目的があります。
1) 不用意な作業の排除: プロジェクトに参加したとき、ワークス
ペース上でビルドがクリーンに作成できるようになるまで、開発者は
試行錯誤するべきではありません。
2) 統一化: 環境が統一されていない場合は、デバッグが難しくなり
ます。つまり、ひとつの環境ではビルドできたものが、もうひとつで
はビルドできないというような事態が発生します。
ƒ ワークスペースを標準化する際のポイントを、以降、解説します。
標準化1 –ワークスペースの標準名
ƒ RADのワークスペースは、各ClearCaseビューごとに、分けましょう
ClearCaseのビュー専用のワークスペースを作成し、かつ、ビューと
ワークスペースを1対1で作成・管理することをお勧めします
ワークスペースのディレクトリは、ローカルのファイルシステムに作る
べきです(バージョン管理下に置いてはいけません)
ƒ ロケーションは、標準化するべきです(例、 “D:¥Workspaces”)
ワークスペースのディレクトリ名には、ClearCaseのビュー名と一致し
た名前をつけるべきです
ƒ Rel3 projectに関係したある開発者のワークスペース名であれ
ば、”D:¥Workspaces¥stef_Rel3_dev”とつけるべきです
複数のビューのプロジェクトを、
1つのワークスペースで管理することは避けてください
標準化2 -ワークスペースのショートカット
ƒ ワークスペースごとに、ショートカットをつくりましょう
(特定のワークスペースを、すぐに立ち上げられるように)
ƒ 手順
デスクトップに、ショートカットを作成してください。(ショートカット名はビュー名と一致
させます。)
作成したショートカットを右クリックし、[プロパティ]を選択します。
“リンク先” の欄を確認します。
“[インストールディレクトリ]¥rationalsdp.exe”以降に、起動オプションを設定します。
※記入例は、以下です。
(インストールディレクトリのパスについては、ご自身のマシンをご確認ください。)
D:¥IBM¥Rational¥SDP¥6.0¥rationalsdp.exe -data “D:¥RSA_Work¥{ビュー名}" -showlocation
※–showlocationオプションをつけると、 ワークスペースを立ち上げた際に、画面上部に、どのディレクトリ
を使用しているのか、表示されるようになり、便利です
標準化3 –環境設定の共有
ƒ ビルド、その他の環境設定など、一貫したワークスペースを準備するた
めの時間を節約しましょう
※エクスポート/インポート時に使用
ƒ チームプロジェクトセットを活用しましょう
プロジェクトの依存関係について理解する手間を省きます
複数のプロジェクトをインポートする時間を節約します
プロジェクト・セット・ファイル (.psf) についても、バージョン管理しましょう
ƒ 共通の作業を格納するためには、シンプル・プロジェクトが有用です
コンパイラーの設定やその他の環境設定の詳細について
新規に参加した開発者に対する初期操作の指示
チーム設定のガイドラインや、その他のワークスペースの設定
標準化4 –外部JARファイルの共有
ƒ 外部JARファイルの共有
ローカルのビルド環境への依存を取り除くために使います
JARファイルのバージョン間の不整合を避けるために使います
ƒ 例)Hiroさんは、あるJARのバージョンXを使用し、同時に、Kenさ
んは、同じJARのバージョンYを使用する
プロジェクトには、ビルドするために必要な全てのJARを入れる必要が
あります
外部JARファイルは、ソースコントロール管理下におく必要があります
ƒ 外部JARに対しては、共通のクラスパスを設定します
ƒ 複数のプロジェクト間で共有されるようなJARについては、共通の
UCMコンポーネントとして登録する必要があります
標準化5 –ClearCaseのチーム設定
ƒ ClearCaseのチーム設定
「新規リソースを追加する場合」⇒「ソース制御を追加するようにプロンプト」
「親ディレクトリーが自動的にチェックアウトされる場合」
⇒ 「親ディレクトリも自動的にチェックイン」
ƒ ブランチやストリームを共有している場合、注意が必要
「状況の最新表示」操作を繰り返し実行
更新指示に応じて状況表示を要求
ƒ 大きいプロジェクトにおいては、パフォーマンスの向上に有効
ƒ その他
多重編集を避けるため、チェックアウト時には「予約」するようにしましょう
ビューで作業をする際には常にアクティビティの指定を要求しましょう
※[ウィンドウ]-[設定]-[チーム]-[ClearCase SCM Adapter]にて、設定します
※設定の詳細については、RADのヘルプを参照下さい
標準化5 –ClearCaseのチーム設定 (補足)
ƒ
RADとClearCaseと連携させる場合には、コントロールパネルの、ClearCaseの
設定について、注意が必要です。
ƒ
以下の手順を参考に、「大文字と小文字を区別しない」設定にして下さい。
1. コントロールパネルを開き、[ClearCase]をダブルクリックし、起動します。”MVFS”タブ
を開き、“Case Isentive MVFS”([大文字と小文字を区別しない])、“Case
Preserving” ”([大文字と小文字を保存する])、にチェックを入れ、[OK]をクリックします。
2. 設定を適用した後は、OSを再起動します
(再起動後、設定が有効になります。)
標準化6 –RAD側の設定
ƒ RAD側の設定として、以下の点を考慮することをお勧めします。
Javaコードのフォーマッティング、エディターの設定は標準化する
ƒ フォーマットが統一されていない場合にはマージ作業が困難になる
ƒ 例)タブ、スペースなど
RAD と UCM の概念のマッピング
ƒ 全てのRADプロジェクトやパッケージに対し、個別にUCMコンポーネントを作成
する必要はありません。
UCMコンポーネントはより高次の定義(例えば、サブシステム)と考えてください。プロ
ジェクトセット使って、コンポーネントのマップをすることはよく使われている手段に
なっています。
一つのUCMコンポーネントの中に、複数の関連するRADプロジェクトを入れるケース
が典型的です( 1:N )
ある1つのアプリケーションに関連する複数のRADのプロジェクトは、一つのUCMプ
ロジェクトのコンテキストの中にいれます
ƒ 徹底の際に有用な情報
ベースラインを作る必要の有無に関わらず、コンポーネントは独立してリリースされる
必要があります
コンポーネントは他のUCMプロジェクトと共有する必要があります
コンポーネントのサイズの合計
コンポーネントの数の合計
(補足)RAD と UCM の概念のマッピング
ƒ 例:コンポーネントのレイアウト
Component A
¥bin
¥JAR files
¥EAR files
¥doc
¥application docs
¥source
¥WSAD Projects
¥My J2EE Project
¥My Web Project
(補足)RAD と UCM の概念のマッピング
RADのプロジェクトは、UCMのコンポーネントとして、VOBに登録・管理されます
ClearCaseビューや、ストリームは、特定のUCMプロジェクトに対して、作られます。
VOB
ストリームは、ビューに対して構成を提供します。つまり、コンポーネントの中から
現在のバージョンとして定義されているものを提供します。RADのプロジェクトは、
ClearCaseのビューから、RADのワークスペースに、インポートします。
注)ClearCaseでは、プロジェクトをインポートする前に、ビューの設定を行います。
Comp A
RAD Workspace
¥MyProject
¥MyProject
1
2
3
File System
3
Stream
3
View
Z:¥SourceVOB
¥MyProject
動的ビューにおける考慮事項
ƒ 動的ビューは、 自動的に更新され、VOB内の最新の変更が反映されます
ƒ Eclipse 3.0 ・ SDP 6.0 製品群では、Windowsのファイルシステムに対する変更が行わ
れた場合、ワークスペースは自動的にリフレッシュされます
ただし、MVFS上で、動的ビューを利用した場合には、自動的にリフレッシュは行なわれません
(2005年6月)
ƒ デリバー、リベース、マージマネージャ、といった操作が実行された場合、ワークスペース
の更新が行われます
RAD の外で、ビューに変更が加わった場合は、手動で更新する必要があります
ƒ 例) ClearCase エクスプローラーからのチェックアウト、チェックイン、マージなど
ƒ ストリームやブランチを共有して使用する際には、注意が必要です
常に、編集する前に、ファイルがチェックアウトされていることを確認して下さい
非接続モードでの作業フロー
ƒ スナップショットビューの更新
ƒ ネットワークからの切断
ƒ RADの開始
デフォルト設定では、ClearCaseへの接続は、自動では行なわれません
必要に応じて、「始動時にClearCaseに自動的に接続」の設定を行ないます
ƒ ファイルをハイジャックする
スナップショット・ビュー内で、読み取り専用のリソースを、編集可能にします
ƒ ネームスペースに関する操作は、避ける
再接続時の修正作業は、非常に困難です
ƒ ネットワークへの再接続
ClearCaseへの接続
ビューの更新と、ハイジャックされたファイルの解決
ソース管理に追加するべきファイルの確認
※パフォーマンスが問題になる場合は、ローカルスナップショットビューを検討します。
※ただし、ワークスペース内のRADプロジェクトには若干のオーバーヘッドが発生します。
Fly UP