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

■ソース・コードの移行

　新規開発の開始時にTFSを導入するのであれば、単純にソリューションをバージョン管理上に登録してやればよいだけである。しかし、既存の開発プロジェクトに対して導入する場合は、そういうわけにはいかない。既存の資産への対応をいろいろと考えなければならないからだ。

○TFSへの移行ツール

　実は、TFS 2008への移行が可能なツールは、それほど多くない。

ツール名	移行元	概要
VSSConverter	Visual SourceSafe	Visual SourceSafeに含まれている移行ツール
Team Foundation Server Migration Tool for Rational ClearCase	Rational ClearCase	マイクロソフトから無償で提供されている移行ツール
表2　TFS 2008への移行ツール一覧
※TFS 2005には、CVSやSubversionからの移行が可能な、有償のCS-Converter（ComponentSoftware社）というツールがあったが、現在開発は行っていないもようである。

　しかも、これら移行ツールを過信するのは危険である。例えば、VSSConverterでは、共有やブランチをそのまま移行できないといったことがある。そもそも違う機能セットを持つシステムに対して、そのまま移行して問題がないわけがない。

○データ移行しないという選択肢

　もちろん、すべてのケースに対応できるわけではないが、筆者は、移行ツールの存在するVisual SourceSafe（以降VSS）やClearCaseについても、必ずしもデータ移行する必要はないと考えている。理由は以下のとおりである。

• ツールを利用したとしても、すべての情報が移行できるわけではない
  前述のとおりである。VSSの共有設定やピン設定など、TFSに存在しない機能の情報は受け継がれないし、それ以外にもすべての情報（システム・メタデータ）が正しく設定されるわけではない。

• 必ずしもすべての履歴を移行する必要があるわけではない
  もちろんすべての状況に当てはまるとはいえないが、最低限移行が必要な情報は、現在開発中のソリューションとリリースされているバージョンのソリューションだけである。

• TFSの機能セットに合わせたソリューション構成を考える
  TFSにはTFSに適したソリューション構成がある。例えば、VSSの共有設定が存在しないTFSで、その機能を前提とした構造は成り立たない。

　筆者は過去に数回、VSSからTFSへの移行を実施しているが、いずれも移行ツールを利用していない。もちろん、規模が小さかったという理由もあるのだが、単純に移行ツールを利用すれば万事OKというわけではないことを忘れないでほしい。

■TFSバージョン管理システムの特徴

　筆者は、過去、.NET開発プロジェクトにおいて、TFSのほかにもVSS、WinCVS、Subversionなどのバージョン管理システムを利用してチーム開発を行ったことがある（また、1度だけではあるが、バージョン管理システムをまったく利用しないチームで開発したこともある）。

　それらの経験を基に、TFSのバージョン管理が持つ以下の機能について、ほかのバージョン管理システムとの比較を交えながら説明していきたいと思う。

• マルチ・チェックアウトとマージ
• 変更セット
• シェルブ
• ブランチ
• 信頼性

○マルチ・チェックアウトと競合の解決

　TFSでは、複数ユーザーによるマルチ・チェックアウトが既定の動作として設定されている。この機能は、Subversionはもちろん、VSSでもサポートされている。VSSでは既定の動作がチェックアウト・ロック（このロックがかけられている間は、ほかの開発者がチェックアウトできない）であったこともあり、あまり認知されていない機能であったようだ。

　当然、複数ユーザーから同時にチェックアウトされるということは、複数ユーザーが同じファイルに対して修正することもあり得る。このような状況をTFSでは“競合”*1と呼んでいる。チェックイン時に、競合が検知されると、図5のダイアログが自動的に表示される。

図5　競合の解決ダイアログ

チェックイン時に、競合が検知されるとこのようなダイアログが表示される。

［すべてを自動マージ］ボタンをクリックすると、自動的にファイルがマージされる。   ［解決］ボタンをクリックするとダイアログが表示され、手動でファイルをマージするか、片方の変更のみを反映するかを選べる。

　競合の解決方法としては、以下の4種類がある。

（1）変更を自動で反映（）
（2）マージ・ツールで変更内容を確認しながら手動で反映（）
（3）ローカルの変更を反映（）
（4）サーバの変更を反映（）

　このうち、最も一般的に利用される方法は、（1）の自動反映である。よく、自動反映は怖いという話を耳にするが、筆者は特に自動マージによりトラブルが発生したことはないため、普通に利用している。ただし、当然ではあるが、競合が同一行に対して発生している場合は自動での反映はできない。どちらの変更を反映するべきかを自動で判断することができないからだ。従って、この場合は、（1）以外のオプションを利用して、手動で競合を解決しなければならない。

*1　Subversionでも競合という用語があるが、この場合は、同一ファイルの同一行が修正されたケースを意味する。SubversionにはTFSで呼ばれるところの“競合”という状態は存在しない（常に自動的にマージされる）。

○変更セット

　変更セットとは、チェックインに関するすべてのデータ（例えば、ファイルとフォルダのリビジョン、関連する作業項目へのリンク、チェックイン・メモ、コメント、ポリシー準拠、およびチェックインの所有者名と日時などのシステム・メタデータ）をグループ化したものであり、TFSでは常にこの変更セットの単位でサーバ上に格納される。

　次の画面は変更セットの履歴を閲覧している例だ。

図6　［変更セット］ダイアログ

［履歴］ウィンドウから過去にチェックインしたすべての変更セットが閲覧可能である。また、コメントや作業項目へのリンクなどをここで修正し、保存することで、過去の変更セットを更新することも可能である。

　VSSでは、変更セットという概念が存在していない。そのため、「障害の発生原因を調査するために、特定のチェックインで何が起きたか調べたい」と思っても、その情報自体が管理対象となっていないため、調査は非常に難しくなってしまう。逆にTFSでは、誰がチェックインしたのかはもちろん、何のタスクにひも付く変更なのか？ （TFSの作業項目管理を実施している場合）誰がレビューしたのか？ （チェックイン・メモを有効にしている場合）ほかにどのようなファイルをチェックインしているか？ などの情報を簡単に検索、閲覧することが可能である。

　ちなみに、変更セットはSubversionでもサポートされている（Subversionではリビジョンと呼ばれる）が、Subversionはタスク管理などの機能を持たないため、TFSに比べて、保持される情報は限定的である。

○シェルブ

　シェルブとは、ユーザーが修正中のソース・コードをチェックインせずにサーバ上に保存するための機能である。ここで保存された内容は、プロジェクトのソース・コード・ツリーには現れない。そのため、ほかのユーザーの作業に影響を与えず、安全に格納することができる。

　格納されたシェルブはクエリで検索することが可能であり、ほかユーザーからも取得する（アンシェルブ）ことが可能である。次の画面は実際にアンシェルブを実行しているところだ。

図7　［アンシェルブ］ダイアログ

［ソリューション エクスプローラ］上のソリューション項目のコンテキスト・メニューにある［保留中の変更をアンシェルブ］を選択することで起動する。ここから格納中のシェルブを検索し、自由に取得することが可能である。逆に、現在の修正状況をシェルブしたい場合は、［保留中の変更をシェルブ］を選択する。

　主にシェルブが利用できるケースとして、以下のようなものが考えられる。

• 帰宅時など作業を中断する際に、変更をローカルではなく、安全なサーバ上に保管したい

• チェックインで変更内容が記録される前に、レビュー担当者にチェックを依頼する

• 現在取り掛かり中の作業一式を、ほかの開発者に受け継ぐ

　この機能は、SubversionやVSSには存在せず、TFSの特徴的な機能である。

○ブランチ／マージ

　まず、ブランチ（分岐）とマージ（統合）の機能を簡単に説明しよう。ブランチとは、あるソース・コード・ファイルのセットを別の場所に分岐し、それにより分岐した時点のクローンを作成する機能である。単なるファイル・コピーとは異なり、ブランチでは、クローン作成時点からのソース・コード・ファイルに対する変更が追跡管理され、最終的に分岐元のソース・コードや別のブランチに変更内容をマージさせることができる。

　このブランチ／マージ機能はバージョン管理システムの基本的な機能であり、ほとんどのツールでサポートされているのだが、VSSと比較すると、パフォーマンスや信頼性の面で、TFSには大きなアドバンテージがある。例を挙げると、そもそもVSSにはフォルダの追跡ができないという問題点がある。また、ブランチ時の処理速度に難がありすぎて、まともに利用できるものではない。

○チェックイン・ポリシー

　チェックイン・ポリシーも、ほかのバージョン管理システムには見られない、TFSならではの機能である。

　チェックイン・ポリシーは、ソース・コード・ファイルをチェックインする際に制約を課すことができる機能であり、標準で以下の3つのルールが提供されている。また、独自にルールを作成することも可能である。

ルール	概要	効果
コード分析	チェックイン前に静的コード分析を実行しなければならない	品質向上
作業項目	チェックイン時に、作業の理由となる作業項目と関連付けなければならない	追跡性向上 不用意な作業を抑える
テスト・ポリシー	チェックイン前に単体テストを実行しなければならない	品質向上
表3　チェックイン・ポリシーの標準ルール

　以下は余談だが、筆者がこの機能について1つ不満に思っていることある。それは、チェックイン・ポリシーのルール設定がチーム・プロジェクトの単位でしか行えないことだ。このため、ソース・コード以外の、制約を課すまでもない成果物（ちょっとした実験用のコードなど）に柔軟に対応するといったことができない（本番用コードと同様のポリシーが適用されてしまう）。個人的には、ポリシーの設定はバージョン管理上のフォルダ単位で設定できることが望ましいと思っており、今後の改善を期待したいところである。

○信頼性

　最後に信頼性（ファイルが壊れてしまわないかなど）についても述べておく。信頼性は機能とは直接関係ないが、バージョン管理システムの根幹になる重要な要素である。この点、SQL Serverを利用するTFSは、そのほかのバージョン管理システムと比較して群を抜いて高いと思う。

　これは筆者の過去の経験からの話で、すべてのケースに当てはまるものではないことをあらかじめお断りしておくが、信頼性という点では、VSSははっきりいって論外である。私がかかわったVSSで開発していた過去のプロジェクトの半分以上で、データベースが壊れてしまったことがある。これは、サーバ・コンポーネントを持たず、クライアントから直接共有ファイルにアクセスするというアーキテクチャ上、やむを得ないことであるのは分かるが。

　また、SubversionもTFSほど信頼性が高いとはいえない。筆者は過去、悪名高い（？）Berkeley DBを利用していたことがあって、そのおかげで何回かリカバリしなければならなかった。TFSでは過去に一度もリポジトリが破損したような事態は起きたことがない。

　TFSのバージョン管理システムの機能説明は以上だ。次は、筆者が実際にプロジェクトでの経験で学んだバージョン管理システムにおけるベスト・プラクティスを紹介したいと思う。

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

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

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