2007/02 ClearCase & UCM の紹介

2,674 views
2,560 views

Published on

2002 年頃にとあるプロジェクトで ClearCase を使っていたことを 2007 年の JavaEE 勉強会で紹介した資料です.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,674
On SlideShare
0
From Embeds
0
Number of Embeds
46
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

2007/02 ClearCase & UCM の紹介

  1. 1. An Introduction to Unified Change Management 統一変更管理の紹介【 小林浩一 (koichik) 【 ます】 見覚え】 あり
  2. 2. Agenda ClearCase概要 UCM 某証券での適用
  3. 3. ClearCase 商用のソ ウェア構成管理ツール フト  CVSやSubversionと同一カテゴリのプロ ト ダク 歴史  Atria Softwareが1992年にリ ース リ  Pure Softwareと 合併し Pure Atriaに て  RationalがPure Atriaを買収  IBMがRationalを買収 現在の製品名  IBM Rational ClearCase
  4. 4. 用語の対応表 CVS/SVN ClearCaseリポジトリ VOB (Versioned Object Base)作業コピー ビューブランチ スト ーム リタグ ベースラ ン イチェッ アウト ク ビュー作成cvs edi (svn l t ock) チェッ アウト クコ ッ ミト チェッ イ ク ン
  5. 5. ClearCaseの特徴 チェッ アウト 修正・ ク ・ チェッ イ ク ンモデル  変更を行うにはチェッ アウト ク 操作が必要  チェッ アウト ク でファ ルをロ ク イ ッ  ロ ク ないでチェッ アウ も ッ し ク ト可  チェッ イ ク ンでファ ルのロ ク イ ッ を解除 ディ ト も レク リ バージョン管理される  ファ ル名の変更や移動も イ 可能
  6. 6. Multi Version File System CVS/SVNは通常のファ ルシステム上に イ 作業コ ピーを作成  メ データ .svnなど)が見える タ (  アプリケーションで無視する必要有り  通常のファ ルアク イ セスは構成管理と無関係 ClearCaseは独自のファ ルシステム上に イ ビュ ーを作成  メ データ タ は見えない  通常のファ ルアク イ セスにClearCaseが 介入できる
  7. 7. Multi Version File System アプリケーション open, read write, close,... OS MVFS Native File System
  8. 8. ビュー ダイ ッ ビュ ナミ ク ー  ローカルのファ ルシステム上にコ イ ピーを持たない  ビューにアクセスがある VOBへアク と セス  ローカルディ にキャ シングはする スク ッ  大規模なシステムでも ーの作成が一瞬 ビュ  コピーしないから  svn updateのよ な操作が不要 う  コピーを持っていないから  ビルド時にはネッ ワーク ト の速度が問題になる と こ も スタ ッ ビュ ティ ク ー  ローカルのファ ルシステム上にコ イ ピーを持つ
  9. 9. Agenda ClearCase概要 UCM 某証券での適用
  10. 10. UCM - 統一変更管理 ClearCaseを使った構成管理の ベスト ク ス プラ ティ ClearCaseに組み込まれている  メ データ VOBで管理 タ を  ツール・ マンド コ のサポート有り  UCMの使用は必須ではない  UCMを使わず素のままCleaCaseを使う と こ を Base ClearCaseと呼ぶ
  11. 11. UCMの構成要素
  12. 12. プロジェクト 変更の大きな単位を表すUCMオブジェクト  PVOB(Project VOB)で管理される タ メ データ  PVOBは複数のプロ ジェク を持つ ト 例  バージョ X開発プロ ン ジェクト  X機能追加プロジェクト プロジェク は一つの統合スト ームを持つ ト リ
  13. 13. 統合スト ーム リ プロジェク の統合用スト ーム ト リ  プロジェク 内のト ンク ト ラ 相当 プロジェク は一つの統合スト ームを持つ ト リ 統合スト ームは複数の開発スト ームを持つ リ リ
  14. 14. 開発スト ーム リ プロジェク の開発者用スト ーム ト リ  開発者は自分専用のスト ームを持つ リ 統合スト ームは複数の開発スト ームを持つ リ リ  プロジェク 内のブラ ト ンチ相当 子の開発スト ームを複数持つこ も る リ と でき  開発チーム毎の統合用開発スト ーム リ  開発フェーズ毎の統合用開発スト ーム リ
  15. 15. シンプルなプロジェク の例 ト X機能追加プロジェクト  統合スト ーム リ  Aさんの開発スト ーム リ  Bさんの開発スト ーム リ . . . Y機能追加プロジェクト  統合スト ーム リ  Aさんの開発スト ーム リ  Bさんの開発スト ーム リ . . .
  16. 16. 複雑なプロジェク の例 ト Z機能追加プロジェクト  統合スト ーム リ  Xチームの開発スト ーム リ  Aさんの開発スト ーム リ  Bさんの開発スト ーム リ  .. .  Yチームの開発スト ーム リ  Mさ んの開発スト ーム リ  Nさんの開発スト ーム リ  .. .
  17. 17. スト ームのポイ リ ント 親子関係がある  統合スト ーム(親)と リ 開発スト ーム(子) リ  親開発スト ームと リ 子開発スト ーム リ 開発者毎に開発スト ームを持つ リ  開発者用のスト ームは共有し リ ない  ロ ク ッ モデルが制約にならない  チェッ イ 他者への公開を分ける と ク ンと こ ができる  SVN等で同一ブランチを複数開発者が使う場合は コ ッ で他者への公開と ミト なる  UCMにおける他者への公開は統合スト ームへのマージ リ
  18. 18. スト ーム間のマージ リ リベース  親から子へのマージ  統合スト ームから リ 開発スト ームへ リ  他者の変更を取り込む デリバー  子から親へのマージ  開発スト ームから リ 統合スト ームへ リ  自分の変更を他者へ提供する
  19. 19. 競合の対処 デリバーの前にリベースする  プロジェク のポリ ト シーで強制でき る コ ンフリ ト ク は開発スト ームで解消 リ  デリバーでは競合は発生し ない
  20. 20. リベースと バー デリ 統合スト ーム リ 参加 参加 開発スト ームA リ 開発スト ームB リ BL0 変更 変更 リベース デリバー BL1 リベース 競合の解消 BL2 デリバー 変更 リベース競合の解消 デリバー BL3
  21. 21. 開発者のマージサイ ル ク 変更・テスト チェ クイン ッデリバー リベース 競合解消・テスト チェ クイン ッ
  22. 22. プロジェク 内のマージ ト 統合スト ーム リ開発スト ーム リ 開発スト ーム リ 開発スト ーム同士では リ マージし ない
  23. 23. プロジェク 間のマージ ト プロジェクト A 統合スト ーム リプロジェクト プロジェクト B C統合スト ーム リ 統合スト ーム リ
  24. 24. UCMのまとめ 型にはめたClearCaseの使い方  ツリー状に階層化されたスト ーム リ  統合スト ーム・ リ 開発スト ーム リ  2つの方向性のあるマージ  リベースしてから バー デリ  親子間でマージ  兄弟ではマージし ない 大規模(大人数)での並行開発に強み  柔軟性には欠ける  だがそれがいい プロジェク の構成は未定義 ト  プロジェク 間のマージをどう ト 運用するか?
  25. 25. Agenda ClearCase概要 UCM 某証券での適用
  26. 26. 某証券 イ ーネッ ・ レーディ ンタ トト ングシステム かなり大規模  Javaソ JSP も イ ース・ と ファ ル数は万単位  多いと は100人以上の開発者 き 1999年に稼働  当初はVisualAge(独自SCM)+CVS(JSP等)  WSADへの移行と 同時にClearCaseへ
  27. 27. 某証券での並行開発 ほぼ毎週新機能リ ース リ  毎週金曜の夜に本番環境へ 大きな機能追加項目が常に多数ある  開発期間はバラ バラ 数日~数ヶ ) ( 月  出来次第リ ースなんてこ も リ と  品質に問題があればリ ースでき リ ない  リ ースの順番は状況次第 (事前に決定でき リ ない) 機能追加項目毎に独立した並行開発が必要  V i A ge+C V Sではマージの負担が制約になった sual  ClearCaseでUCMの導入へ
  28. 28. 某証券でのプロジェク 構成 ト メ ンラ ンプロ イ イ ジェクト 本番リ ース用の リ  mainline-integration 成果物を作成する プロジェクト  mainline-next_release メンテナンスプロジェクト 専用のプロジェ を クト  maintenance-integration 作るほどではない小さ 変更はここで行う こで行う な  開発スト ーム・・ リ ・ X機能追加プロジェクト 常時10以上の 機能追加プロジェ が クト  x-integration アクティブ  開発スト ーム・・ リ ・
  29. 29. プロジェク 間のマージ ト メインライン プロジェクト 本番リ ース後 リ リベース・ バー デリメンテナンス X機能追加プロジェクト integration プロジェクト統合 next_release 統合 週末リ ース予定の リリ 本番リ ース後開発 プロ ク を週の初めに 開発 リジェ ト デリ ベース・ バー リベース・ バー デリ
  30. 30. 参考文献 Software Configuration Management Strategies and IBM Rational ClearCase  ISBN0-321-20019-5 The Art of ClearCase Deployment  ISBN0-321-26220-4

×