次の方法で共有

  • [アーティクル]

June 2012

Volume 27 Number 06

ALM Rangers - TFS 統合ツールを使用してオンプレミスの Team Foundation Server を Team Foundation サービス プレビューに移行する

Willy-Peter Schaub | June 2012

今回は、オンプレミスの Microsoft Team Foundation Server (TFS) 2010 を、最新の TFS 統合ツールを使用して Team Foundation サービス プレビュー (英語) へ移行します。これらのツールはプレビュー期間か、少なくともホスト型のサービスがより直接的なアタッチまたはデタッチのエクスペリエンスを提供するまで利用できます。今回の目的は、この製品の主要機能をいくつか紹介し、製品ドキュメントに記載されている技術情報とガイダンスを補足することです。

デモ アプリケーションは、Microsoft Visual Studio ALM (アプリケーションのライフサイクル管理) Rangers が開発しました。あまりご存じないかもしれませんが、ALM Rangers は、不足している機能に取り組み、導入の障害を取り除き、実際の経験に基づきベスト プラクティスとガイダンスを発行することで、Visual Studio 製品グループ、Microsoft サービス、および Microsoft Most Valuable Professional (MVP) コミュニティの連携を促進する専門家集団です。

TFS と TFS 統合ツールとそれぞれの使用タイミングについて

TFS 製品グループと ALM Rangers は TFS 統合ツールを開発し、TFS をサードパーティ製のシステムと統合して、サーバー間でソース管理と作業項目のデータを移行および同期できるようにしました。これらのツールは TFS 間でのデータのコピーにも使用できます。  

移行ガイダンスのドキュメントで強調しているように、これらのツールの使用を決める前に、計画およびテストし、メンテナンスに必要なリソースとコストを注意深く評価する必要があります。

TFS 統合ツールに含めた製品ドキュメントは、[スタート] ボタンをクリックし、[すべてのプログラム]、[Microsoft Team Foundation Server Integration Tools] (Microsoft Team Foundation Server 統合ツール) の順にポイントして、[Documentation] (ドキュメント) をクリックすると表示されます。

製品ドキュメントは、次のような主要分野に対応します。

  • 移行ガイダンスは、TFS 統合プラットフォームのアーキテクチャを支える TFS 統合ツールの機能と主なアーティファクトを、ALM Rangers が提供する付加価値と共に紹介します。
  • 概念実証 (POC) チェックリストは、プロジェクトを迅速化し、移行 POC の実行に役立つテンプレートとサンプル ドキュメントです。
  • 実践ハンズオン ラボは、TFS 統合ツールを実演します。
  • 構成例は、これまでの POC の構成ファイルの例を豊富に含みます。
  • ツール設定は、ツールの使用に的を絞ったドキュメントを含みます。
  • よくある競合とその解決方法は、競合と解決に関するヘルプ ファイルにまとめています。
  • TFS 統合プラットフォーム SDK は、カスタム アダプターの開発者向けに SDK を要約したコンパイル済みのヘルプ ファイルです。
  • TFS 統合ツール TOC (英語) のブログ ポスト、TFS の移行と統合ソリューション (英語) のサイト、IBM Rational から TFS への移行の概要 (英語) のブログ ポストなどの参照サイトは、目的に応じて製品について学び評価するのに役立ちます。

製品ドキュメントについてのより詳細な紹介については、私のブログ ポスト「Where does one start? … part 1 (documentation)」(どこから開始すればよいか … 第 1 部 (ドキュメント)、英語) を参照してください。ドキュメントを調べるときは、2 つのクイック リファレンス ポスターとチェック シートが役立ちます。

TFS 統合ツールは、バージョン管理 (VC) データ、作業項目追跡 (WIT) データ、および両方のリンクを、整合性を保ちながら移行するのに役立ちます。また、チーム プロジェクトをまとめ、別のチーム プロジェクトプロセス テンプレートに移行するのにも利用できます。今回は取り上げませんが、移行が現実的ではない場合に限り、同期が重要になります。マイクロソフトのドッグフーディング環境 (「VSTS Pioneer TFS dogfood server」(VSTS Pioneer TFS ドッグフード サーバー、英語)) では、最新版の TFS に完全に切り替えるのは作業環境に多大な影響を与え、業務の停止を引き起こすため現実的ではない場合の、典型的な同期の例が紹介されています。

注: TFS 統合ツールは、履歴データをホスト型の TFS に移行する、現在のところ唯一の方法です。ID と移行日時の制限事項に注意し、過去のデータの作成や変更がサポートされないことを覚えておいてください。

適切なバージョンのダウンロード

TFS 統合ツールは、CodePlex (英語) と Visual Studio ギャラリー (英語) のどちらでも利用できます。CodePlex のバージョンには、未リリースのアダプターなど、最新の Beta 機能を含みます。Visual Studio ギャラリーのバージョンには、ツールの最新の完全サポート対象のリリースを含みます。サポート オプションの詳細と、特に問題が発生したときのサポート要請方法については、私のブログ ポスト「How do I call for support」(サポートを要請するには、英語) を参照してください。

移行の計画

図 1 に示すように、ここで取り上げる移行では、オンプレミスの TFS 2010 の AFE_TFSIterationAutomation チーム プロジェクトを、TFS プレビュー (英語) によってホストされる AFE_Demo チーム プロジェクトに移行します。スクラムベースのチーム プロジェクトからターゲット環境のスクラムベースのプロジェクトへの移行を行うため、カスタム フィールド データのマッピング規則を作成する必要はありません。

オンプレミスからホスト型環境への移行
図 1 オンプレミスからホスト型環境への移行

TFS 統合ツールでは、拡張フィールドと値マッピングの機能が提供されますが、これらはすぐに複雑になり、異なるプロセス テンプレート間で移行するときに、必要なフィールドと値のマッピングを設計および構成するのに時間がかかります。類似したプロセス テンプレート (つまり、Scrum 1.0 と Scrum 2.0) の場合は、フィールドのマッピング規則は必要だとしても少しで済みますが、スクラムを能力成熟度モデル統合 (CMMI) に移行する場合は、より多くの規則が必要になります。

前提条件の準備

移行を始めるのに必要な前提条件は主に 3 つです。

最新の TFS 統合ツールのインストール

Team Foundation サービス プレビュー (英語) への移行でお勧めのバージョンは 2012 年 3 月 (英語) (または利用可能な場合はそれ以降) のリリースです。2011 年 3 月のインストールを 2012 年 3 月のリリースにアップグレードできます。

ツールをインストールするには、Microsoft Team Foundation Server 統合ツール セットアップ ウィザードを使用します。カスタム セットアップ ページで、機能のインストール方法を選択します。今回のデモでは、TFS 統合サービスと IBM Rational 環境の選択はどちらもサポートしていません。TFS 統合サービスは、バックグラウンド移行および同期実行と、統計収集に役立ちますが、どれもデモには必要ありません。

Visual Studio チーム エクスプローラーのインストール

使用する TFS のすべてのバージョンに対応する Visual Studio チーム エクスプローラー (VSTE) をインストールする必要があります。たとえば、VSTE 2010 と VSTE 11 をインストールしていると、[スタート] ボタンをクリックし、[すべてのプログラム]、[Microsoft Team Foundation Server Integration Tools] (Microsoft Team Foundation Server 統合ツール) を順にポイントし、[TFS Integration tool] (TFS 統合ツール) をクリックしても、TFS 統合ツール 2008 アダプターは表示されません。Visual Studio チーム エクスプローラーは Visual Studio 2010 と Visual Studio 11 に含まれているので、既に IDE がインストールされている場合はこの手順を省略できます。

必要なアクセス許可の確保

製品をインストールしたら、ソースとターゲットの両方の環境で必要最低限のアクセス許可を確保します。デモ移行を正常に完了するため、移行ユーザーは TFS アカウント グループに所属し、適切な資格情報を所持していなければなりません。

接続を確認するには、ソースとターゲットのチーム プロジェクトの両方に接続し、TFS 統合ツールがインストールされたコンピューターで VSTE を使用します。

移行の構成

まず、ソースとターゲットのエンドポイントを構成します。このタスクは非常に簡単で、直感的に行えます。まず、[スタート] ボタンをクリックし、[すべてのプログラム]、[Microsoft Team Foundation Server Integration Tools] (Microsoft Team Foundation Server 統合ツール) を順にポイントしたうえで、[TFS Integration] (TFS 統合) をクリックして TFS 統合ツールの管理ユーティリティを開始します。新しいセッションを作成するには、[TFS Integration] (TFS 統合) ダイアログ ボックスの、左のナビゲーション ウィンドウの [Configuration] (構成) の下の [Create New] (新規作成) をクリックします。[Choose a template] (テンプレートの選択) ダイアログ ボックスで、VersionControlAndWorkItemTracking 構成テンプレートを選択し、バージョン管理および作業項目追跡テンプレートと、関連するリンクを移行します (図 2 参照)。

VC および WIT テンプレートの選択
図 2 VC および WIT テンプレートの選択

次に、Left Source を構成します。これは、図 1 に示したオンプレミスの TFS 2010 です。構成を、図 3 に示します。

セッションの構成
図 3 セッションの構成

図 3 の 1 から 4 までの数字に注目してください。これらは、その他の構成タスクを示しています。

  1. ここでの目的はオンプレミスから TFS プレビューでホストされたチーム プロジェクトへの移行なので、[Workflow type] (ワークフローの種類) では [One-way migration] (1 方向の移行) を選択します。
  2. ソースの [Version Control Session Provider] (バージョン管理セッション プロバイダー) には、TFS 2010 移行 VC プロバイダーを選択します。
  3. [Work Item Tracking Session Provider] (作業項目追跡セッション プロバイダー) には、TFS 2010 移行 WIT プロバイダーを選択します。
  4. 上図の 2 つのエラーは、ターゲット セッションの構成も必要だということを示しています。

次に、[Right Source] (適切なソース) を構成します。図 4 に示すように、TFS プレビュー環境 (図 1 参照) を構成します。このプロセスでは、前提条件の準備の段階で Visual Studio 11 の接続をテストした際、LiveID の認証ダイアログで [サインアウトしない] チェック ボックスをオフにしている場合は、資格情報の入力が求められます。

ターゲット セッションの構成
図 4 ターゲット セッションの構成

図 5 に示すように、VC パスは変更しないで既定のままにします。サポート対象の構成オプションについては、インストールに含めた構成ガイドを確認してください。

既定の VC パス
図 5 既定の VC パス

WIT クエリを [System.TeamProject] = @project and [System.WorkItemType] <> 'Sprint' に変更し、Sprint 以外の WIT 型をすべて返します (図 6 参照)。

Sprint WIT 以外をすべて返す WIT クエリ
図 6 Sprint WIT 以外をすべて返す WIT クエリ

注: 起こり得る競合シナリオを検出するため、計画にはソースとターゲットの VC と WIT のソリューションの詳細な分析を含めます。これに代えて、少量のデータを簡単に移行してみて、この段階の既定の構成を使用して、移行エラーと競合を分析することも可能です。

この簡単なテスト移行を実行する際に、Microsoft Visual Studio Scrum 1.0 プロセス テンプレートと Microsoft Visual Studio Scrum 2.0 - Preview 3 とは一致しないことがわかります。これは、フィールドのマッピングは不要という想定と矛盾します。

図 7 に示すように、フィールドと値のマッピングなどの高度な機能を構成するには、ちょっと身構えて、XML ボタンか XML タブをクリックし、XML 構成ファイルを操作する必要があります。

XML 構成ファイルの編集
図 7 XML 構成ファイルの編集

フィールドと値のマッピング機能を実演するため、図 8 に示したユーザー アカウントをマップします。ソース システムのユーザー Willy-Peter Schaub を、ターゲットのユーザー A@Test.com にマップします。それ以外のユーザーはすべてユーザー X@Test.com にマップします。

静的ユーザー マッピング
図 8 静的ユーザー マッピング

注: フィールドと値のマッピングをユーザー マッピングに使用するのは、ユーザー数が少ない場合に適しており、このデモの良い例になります。ユーザー ベースが大きい場合は参照サービスを調べますが、ホスト型のサービスではユーザーを参照する場所がないため、残念ながらこれは機能しません。詳細については、製品ドキュメントか、「What is the Lookup Service」(参照サービスとは何か、英語) と「How do I map users between domains or systems」(ドメインまたはシステム間でユーザーをマッピングするには、英語) を参照してください。

次に、WIT セッションで [Edit XML] (XML の編集) をクリックし、構成 XML ファイルを編集します。構成変更のいくつかは手動で行う必要があります。図 9 に示すのは、構成が終わった SettingXml セクションです。

<SettingXml>
    <WITSessionCustomSetting>
       <Settings />
       <WorkItemTypes>
           <WorkItemType LeftWorkItemTypeName="Bug"
                         RightWorkItemTypeName="Bug" fieldMap="FieldMap" />
           <WorkItemType LeftWorkItemTypeName="Product Backlog Item"
                         RightWorkItemTypeName="Product Backlog Item"
                         fieldMap="FieldMap" />
           <WorkItemType LeftWorkItemTypeName="Task"
                         RightWorkItemTypeName="Task" fieldMap="FieldMap" />
       </WorkItemTypes>
       <FieldMaps>
           <FieldMap name="FieldMap">
                <MappedFields>
                   <MappedField LeftName="*" RightName="*"
                                MapFromSide="Left" valueMap="" />
                   <MappedField LeftName="System.Description"
                                RightName="" MapFromSide="Left"
                                valueMap="" />
                   <MappedField LeftName="Microsoft.VSTS.Common.DescriptionHtml"
                                RightName="System.Description"
                                MapFromSide="Left" valueMap="" />
                   <MappedField LeftName="System.AssignedTo"
                                RightName="System.AssignedTo"
                                MapFromSide="Left" valueMap="UserMap" />
                </MappedFields>
           </FieldMap>
        </FieldMaps>
        <ValueMaps>
            <ValueMap name="UserMap">
                <Value LeftValue="Willy-Peter Schaub"
                       RightValue="A@Test.com" />
                <Value LeftValue="*" RightValue="X@Test.com" />
            </ValueMap>
         </ValueMaps>
     </WITSessionCustomSetting>
  </SettingXml>

図 9 XML 構成ファイルの抜粋

作業項目の型、Bug、Product Backlog Item、および Task を構成して処理します。それ以外の型は、移行ではすべて無視します。すべての作業項目の型は、FieldMap という共通のフィールド マップを参照しています。これで、図 10 に示すマッピングが作成されます。

カスタム フィールド マッピング
図 10 カスタム フィールド マッピング

このマッピングの方法を以下に示します。

  • * -> * マッピングから開始しました。オーバーライドがない限り、すべてのフィールドを左から右へ移行します。
  • System.Description -> なし、のマッピングを定義し、ソースの System.Description フィールドを対象からはずします。非 HTML フィールドは最新の Visual Studio Scrum 2.0 - Preview 3 プロセス テンプレートを使用したターゲットには存在しません。
  • Microsoft.VSTS.Common.DescriptionHtml ソース フィールドの System.Descriptiontarget フィールドへのマッピングを定義しました。System.Description は、最新の Visual Studio Scrum 2.0 - Preview 3 プロセス テンプレートの HTML 型です。
  • 最後に、System.AssignedTo を左から右へマッピングして、UserMap というカスタム valueMap を使用します。
  • UserMap で、Willy-Peter Schaub を A@Test.com に、その他のすべてのユーザー (*) を X@Test.com にマッピングするために 2 つの値を定義しました。

その後、XML ファイルを閉じ、変更がすべて作業項目の種類セッションの [Customs Settings] (カスタム設定) セクションに正しく表示されることを確認します (図 11 参照)。

作業項目の種類セッション マッピングのカスタマイズ
図 11 作業項目の種類セッション マッピングのカスタマイズ

最後に、[Save to Database] (データベースに保存) をクリックして、データベースに構成を保存します。

移行の実行

この移行のテスト実行を開始するには、[TFS Version Control and Work Item Tracking with Links] (TFS バージョン管理および作業項目追跡とリンク) ダイアログ ボックスで、左のナビゲーション ウィンドウの [Current Migration] (現在の移行) の下の [Start] (開始) をクリックします (図 12 参照)。ツールは、構成したセッションの分析と移行の手順を処理する間、さまざまなフィードバックを表示します。

移行のテスト実行開始
図 12 移行のテスト実行開始

移行状態のフォームを図 13 に示します。総合インジケーター (1) は移行状態 (この場合は Stopped (停止)) と競合の数を表示します。各セッションには、固有の詳細状態があります。バージョン管理セッション (2) の発行があるのと、作業項目追跡セッションが 233 WIT の変更を正常に移行したのを確認できます。

移行状態のフォームにおける進行状況インジケーター
図 13 移行状態のフォームにおける進行状況インジケーター

状態フォーム下部の、[History] (履歴) タブに進行状況を示す棒グラフがあります。図 14 に示す赤いグラフは問題 (競合) を表しています。図 15 に示す黄色の棒は進行中の作業を表し、緑の棒は完了した移行タスクを表します。

エラーを示す [History] (履歴) タブ
図 14 エラーを示す [History] (履歴) タブ

正常に進行していることを示す [History] (履歴) タブ
図 15 正常に進行していることを示す [History] (履歴) タブ

[Output] (出力) タブ (図 16 参照) は、現在のセッションでディスクに書き込まれた詳細移行ログを示します。このログは、サポートを要請するときに通常必要になるアーティファクトの 1 つで、移行プロセスについて学習し、移行をデバッグするのに役立つツールです。

詳細移行ログを表示する状態フォームの [Output] (出力) タブ
図 16 詳細移行ログを表示する状態フォームの [Output] (出力) タブ

問題解決や検証の一部としての状態とログ情報の分析の詳細については、「Troubleshooting an unhappy migration world」(厄介な移行の世界で問題を解決する、英語) を参照してください。

競合の解決

競合の解決は、厄介な課題になる可能性があります。競合を理解し、パターンを認識して、今後の移行においてよくある競合を避けるために事前に計画することには、時間をかけるだけの価値があります。MergeScope や Cloaking などの機能は、移行についてよく調べ、競合などの問題を事前に回避するのに役立ちます。

開始するには、[Resolve] (解決) リンクをクリックし、競合の一覧に移動します (図 17 参照)。

Conflict list
図 17 競合の一覧

移行中に VC 競合が検出されました。原因は、ソース プロジェクトと作成した新しいターゲット プロジェクトに、同じアップグレード テンプレート ファイルの一部が存在することです。競合の解決がどのように行われるかを示すため、この競合はデモに残しました。クローキングなどの機能を使用して事前にこの競合を避けることもできます。クローキングの詳細については、「TFS Integration Tools – What is the difference between cloaking and scoping branches?」(TFS 統合ツール – 分岐のクローキングとスコーピングの違い、英語) を参照してください。

注: VC 競合は "バスを停止" します。つまり、VC セッションの移行は競合が解決するまで停止します。

競合を解決するには、ソースのチーム プロジェクト (図 18 参照) とターゲットのチーム プロジェクト (図 19 参照) に関連する変更セットを見つける必要があります。

ソースのチーム プロジェクトの変更セット
図 18 ソースのチーム プロジェクトの変更セット

ターゲットのチーム プロジェクトの変更セット
図 19 ターゲットのチーム プロジェクトの変更セット

ソース、ターゲット、または 2 つをマージしたバージョンのどれが必要なのかを判断する必要があります。ソースまたはマージ バージョンが必要な場合、ターゲット ワークスペースのファイルを手動でチェックアウトし、内容を変更して、チェックインする必要があります。

注: ブログ ポストの「TFS Integration Tools – VC Conflict “A namespace conflict has been detected” … what now?」(TFS 統合ツール – VC 競合 "名前空間の競合が検出されました" … とは何か、英語) には、競合解決の例を紹介しています。

競合を解決してから移行セッションを再開すると、結果はシンプルになります (図 20 参照)。

最終移行状態
図 20 最終移行状態

TFS 統合の競合および解決のヘルプを立ち上げると、いつでも競合解決についての追加情報が見つかります。

移行の検証

TFS 統合ツールが "completed successfully" (正常に完了しました) と報告したら、VC と WIT のデータが想定どおりに移行されたか検証する必要があります。たとえば、製品バックログ項目をランダムに調べ、履歴を含むすべての情報が移行されていることを確認します (図 21 参照)。

サンプルの WIT 項目
図 21 サンプルの WIT 項目

より重要なのは、ソース システムのバグ (図 22 参照) と、ターゲット システムに移行したバグ (図 23 参照) を調べるとき、カスタム フィールドマッピング構成が想定どおりに機能することを確認することです。

ソース システムのバグの一覧
図 22 ソース システムのバグの一覧

ターゲット システムのバグの一覧
図 23 ターゲット システムのバグの一覧

まとめ

今回取り上げた簡単なデモでは、パイロット移行の際に TFS 統合ツール ガイダンスが何を示すかを説明しました。この説明から、チームはツールの使用、ソース データ、移行の要件、および競合の解決を理解できます。運用環境にツールを実装する前に、こうしたパイロット移行を数多く実行することをお勧めします。運用環境で想定外の競合が発生すると、開発チームに影響して開発作業が停止する場合があります。このようなシナリオは経験しないにこしたことはありません。

余分なリソース

TFS 統合ツールを試すとき、テスト用のチーム プロジェクトを数多く作成することになり、必要もないのに、TFS 統合ツールを再インストールしてクリーン状態から開始しようと考えるかもしれません。移行の試行の結果、ワークスペース マッピングなどの行き場のないリソースが生じます。

移行を通じて作成したチーム プロジェクトとワークスペースをクリーンアップするのに役立つコマンドの例を、いくつか紹介します。

  • 不要なテスト用チーム プロジェクトを削除する

以下の tfsdeleteproject コマンドを使用して、テスト プロジェクトをすべて削除します。

tfsdeleteproject /collection:https://demoonly.tfspreview.com/DefaultCollection AFE_Demo
tfsdeleteproject /collection:https://demoonly.tfspreview.com/DefaultCollection AFE_Demo1
tfsdeleteproject /collection:https://demoonly.tfspreview.com/DefaultCollection AFE_Demo2
  • 移行で作成されたワークスペースを見つける

tf workspaces コマンドを実行し、移行ツールキットで作成したワークスペースを探します (図 24 参照)。TFS 統合ツールは、多くの場合、セッション完了時にワークスペースをクリーンアップしますが、すべて想定どおりに機能した時点でクリーンアップすることもお勧めします。

移行ワークスペース
図 24 移行ワークスペース

  • 不要なワークスペースを削除する

tf workspace /delete コマンドを使用して、不要なワークスペースを削除します。

tf workspace /delete /collection:https://demoonly.tfspreview.com/DefaultCollection "WILLYS-EAGLE8b877b267b7e4641a36657663184c18aalmrangers.tfsprevie;Willy-Peter Schaub"

以下にいくつか役立つ URL を紹介します。

WillyPeter Schaub は、Microsoft Canada Development Center で、Visual Studio ALM Rangers のシニア プログラム マネージャーを務めています。1980 年代中ごろから、ソフトウェア エンジニアリングにおける簡潔さと保守性を追求し続けています。彼のブログは blogs.msdn.com/b/willy-peter_schaub (英語) で公開されており、Twitter (www.twitter.com\wpschaub、英語) でフォローできます。

この記事のレビューに協力してくれた技術スタッフの Patricia Wagner、Bill Essary、Bijan Javidi、Doug Neumann、Thomas Schissler、および Adam Jagocki に心より感謝いたします。