連載：Team Foundation Server 2008の下流工程への適用 第2回 チーム開発におけるバージョン管理の活用方法 アバナード株式会社　安藤 大祐（Microsoft MVP 2008 for Team System） 2008/12/26
Page1 Page2 Page3

■筆者が勧めるバージョン管理のノウハウ

　ここまででは、TFSの機能を説明してきた。以降は、もう一歩進め、TFSの機能をどのように利用すれば効果的なのかという点について説明していきたいと思う。内容は以下のとおりだ。

• Visual Studio環境設定のカスタマイズ
• チーム・プロジェクトの作成単位
• ブランチの作成方針
• チェックイン・ポリシーの適用方針

○バージョン管理の目的

　ベスト・プラクティスの説明をする前に、筆者の思うバージョン管理の目的を以下に定義しておこう。

目的

• チーム開発や並行開発により発生する作業の損失を最小限に抑える（生産性の向上）
• ビルドが復元可能であること（信頼性の向上）

　なお、筆者が以降で想定しているのは、エンタープライズ・アプリケーション開発におけるベスト・プラクティスである。従って、パッケージ開発などに従事している方にとっては、内容に違和感があるかもしれないが、そこは留意していただければと思う。

○Visual Studio環境設定のカスタマイズ

　筆者はTFSを利用する際に、必ず環境設定をカスタマイズし、［チェックイン項目］の動作オプションを［チェックアウトを確認する］に変更する。

図8　ソース管理の環境設定（［オプション］ダイアログ）

[チェックイン項目]では、ソース管理されているファイルに対して修正を加えた場合に、そのファイルを自動的にチェックアウトさせるか否かを選択することができる。

　理由は、Visual Studioがビルド時に勝手にファイルを編集することが多いからである。上記オプションに変更しておけば、ファイルが書き換えられたことに気付かずにチェックインしてしまうといったリスクを最小限に抑えられる。

○チーム・プロジェクトの作成単位

　チーム・プロジェクトというぐらいだから、チーム単位で作成すればよいのではと思うかもしれないが、そう簡単な話でもない。チーム・プロジェクトについてもう一度おさらいしておこう。

　チーム・プロジェクトとは、TFSの各種機能を実際に利用するために必要な領域である。つまり何がいいたいかというと、バージョン管理はもちろん、作業タスクや要件といった項目を管理する作業項目管理やレポーティングなどの機能もすべてチーム・プロジェクト単位で作成されてしまうということだ。

　開発チーム内のメンバーであれば当然それで問題はないのだが、複数の開発チームを束ねるPMO（プロジェクト・マネジメント・オフィス）といったチームから見ると、プロジェクト全体といった単位で状況を確認したいものである。逆にすべてを1つにまとめてしまうと、チェックイン・ポリシーやプロセス・ガイダンスなどの開発規則がすべてのチームに適用されてしまい、柔軟な対応がしづらくなってしまう。情報量が増えてしまって、各チームの速度が鈍ってしまうことも考えなければならない。

　従って、なかなか単独の答えを出すのは非常に難しく、状況に応じて判断するしかない。以下に2つのケースを挙げる。

・ケース1：プロジェクトに単一の開発チームしか存在しない場合

　このケースなら答えは簡単だ。チーム単位で作成すればよい。最初は開発チーム用に1つのチーム・プロジェクトを用意する。そしてシステム・リリース後、別に運用チームが立ち上がる場合は、従来の開発チーム用のチーム・プロジェクトは次バージョンの開発用にそのまま流用し、運用チーム用に新たにチーム・プロジェクトを作成すればよい。

・ケース2：プロジェクトに複数の開発チームが含まれる場合

　問題はこのケースである。大規模プロジェクトという想定で考えると、各チームは異なる会社である可能性も非常に大きく、できればチーム・プロジェクトは分けて管理したい*2。ただし、もちろん最終的にリリースされるシステムはすべてのチームの成果物が結合されたものでなければならないし、管理は全チーム横断的に実施したいという思いもある。

*2　もちろん、TFS自体を共有しないという選択肢もあり得るが、最後の最後でビックバン結合といったリスクを回避するためにも、可能な限り同一のリポジトリを共有する方向で考えるべきだと筆者は思っている。

　そこで筆者は以下のような構成を提案する。1つマスタとなるチーム・プロジェクトを作成し、開発チームごとに作成したチーム・プロジェクトをブランチとして見なす方法である。

図9　大規模プロジェクトにおけるチーム・プロジェクト構成

※1 TFSのデータ管理という観点でいえば、チーム・プロジェクトというのは、区分やイテレーションといったものと同様、属性の1つでしかない。例えば、作業項目を検索する際に、現在のチーム・プロジェクトの結果しか返されないのは、単にクエリの条件として設定されているだけである。従って、この条件を外すだけで、ほかのチーム・プロジェクトの作業項目を検索することが可能となる。

※2 可能であれば、この段階で自動化されたリグレッション・テストを実施することを検討したい。これにより、早期でのバグの検出が可能となり、かつメイン・チーム・プロジェクト内に格納されているソース・コードの品質を一定上の水準（顧客の環境への移行が可能なレベル）であると保証することができる。

　この方法であれば、個別にしたいという要求と一元管理したいという要求の2つを解決できる。欠点は見てのとおり、複雑すぎることだ。ただ、このような規模になってしまうと、管理に複雑さが出てしまうのは、ある程度やむを得ないことだと思うし、管理作業の一部をTFSのテクノロジでカバーできる分、まだマシであるかと考えている。

○ブランチの作成方針

　ブランチに関しては、重要な原則が存在する。それは、可能な限りブランチを作らないことである。なぜならば、マージの管理、そしてマージ作業自体には大きなコストやリスクが伴うからである。ブランチを作成するのは、以下のようなサインが出てきたときだけにすること。

• 複数のチームでの並行作業が必要である
  　これは、上述のチーム・プロジェクトに関するノウハウで示したとおりである。運用チームなどに成果物が引き継がれる場合は、ブランチを作成し、追跡が可能でなければならない。

• 異なるリリース日の開発を同時に進めなければならない
  　次バージョンに対する開発と、緊急の障害対応を同じコード・ベースで行うことはできない。このようなケースでは、リリース時点の日付やラベルを基にブランチを作成し、障害対応を実施しなければならない。

図10　メンテナンス向けに作成するブランチ

　なお、リポジトリ上にVisual Studioソリューションを登録する際は、ブランチを考慮した構成にしておくとよい。

図11　バージョン管理のフォルダ構成

○チェックイン・ポリシーの適用方針

　チェックイン・ポリシーは便利な半面、前述のとおり設定に柔軟性が乏しく、使い方を間違えてしまうと、開発者のリズムを崩してしまう可能性があるため、設定は必要最低限にしたい。

　アジャイル開発のベストプラクティスに、継続的インテグレーション（以下CI）というものがある。これは、結合時に発生するリスクやバグの潜伏期間を最小限にすることを目的としたもので、“ビルドやテストのすべてが自動化”された、“再現可能なビルド”を“日に何度も”行うこととしているパターンである。TFSでもCIはサポートされており、自動ビルド、自動テストの実施をスケジューリングしたり、チェックインをトリガに実行したりできる。

　チェックイン・ポリシーの一部は、このCIと目的がかなり似ている。両者の違いといえば、結合をサーバで自動的に行うのか（CI）、結合を各クライアントで行うよう強制させるか（チェックイン・ポリシー）である。

　当然CIはサーバ上で自動的に実行されるため、開発者に負荷はかからず、リズムを崩すといった心配はない。従って、CIにより代替案のあるポリシーは、可能な限りそちらに寄せてしまい、チェックイン・ポリシーの負荷を小さくするべきである。次の表に、一般的にCIで対応可能なチェックイン・ポリシーをまとめた。

チェックイン・ポリシー	CIでの代替案
コード分析	自動ビルド中でのコード分析の実施
テスト・ポリシー	自動ビルド中での単体テストの実施
表4　CIで対応可能なチェックイン・ポリシー

■まとめ

　今回は、TFSのバージョン管理システムの機能と筆者の考えるベストプラクティスを説明した。利用するうえでの勘所を一通り理解していただけたかと思う。次回は応用編として、TFSのバージョン管理を利用したコードレビューの方法について説明していきたいと思う。

INDEX
	[連載] Team Foundation Server 2008の下流工程への適用
	第2回 チーム開発におけるバージョン管理の活用方法
	1．チーム・プロジェクトの構築
	2．ソース・コードの移行／TFSバージョン管理システムの特徴
	3．筆者が勧めるバージョン管理のノウハウ

「Team Foundation Server 2008の下流工程への適用」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）