MSF v4.2 プロセス テンプレートに基づくチーム プロジェクトの更新

Visual Studio Team System 2008 Team Foundation Server から Team Foundation Server 2012 にアップグレードした場合は、チーム プロジェクトを手動で更新できます。チーム プロジェクトが Microsoft Solutions Framework (MSF) のバージョン 4.2 のプロセス テンプレートに基づいている場合、このトピックの手順に従ってください。これらの更新を追加したら、アップグレードされたチーム プロジェクトの更新による新機能の利用 で説明する新しい機能にアクセス、または Microsoft Test Managerとやり取りできます。

重要
、Visual Studio Team System 2008 Team Foundation Serverを受けたプロセス テンプレートで作成した場合は、作業項目の種類のテスト ケースと共有ステップを含まない 1 をチーム プロジェクトをアップグレードする場合にのみ、このトピックの手順に従う必要があります。 これらの手順は Team Foundation Server 2012 で使用できる新しい機能へのアクセスのみをサポートします。特別な処理は新しいクエリまたは最新のレポートを、カスタマイズされたレポート追加、またはアクセスのダッシュボードを更新するために必要です。詳細については、TFS をアップグレードするときに行われた変更に関する追加情報を参照してください。

新しい機能にアクセスするために必要なタスクを更新します。:

1. 名前の変更のシステム フィールド

2. (のみ)、ユーザー ストーリーの名前の変更のシナリオ

3. MSF プロセス テンプレートの最新版をダウンロードします。

4. リンクの種類をインポート

5. (省略可能) 必要なカスタマイズとして適用します。

6. 作業項目の種類をインポート

7. カテゴリ ファイルをインポートする

8. プロセスの構成ファイルのインポート

9. 新しい機能へのアクセスを確認します。

Microsoft テスト マネージャーとやり取りするために必要な追加のタスク:

1. Microsoft テスト マネージャーで作成するバグの種類を指定します。

2. テスト チーム メンバーに付与するアクセス許可

3. スタートアップ Microsoft テスト マネージャー

要件

• プロセス テンプレートをダウンロードするには、[プロジェクト コレクション管理者] グループのメンバーである必要があります。必要なセキュリティ アクセス許可が明示的に設定されている場合は、チーム プロジェクト コレクションの [プロセス テンプレートの管理] のアクセス許可が [許可] に設定されている必要があります。

• witadmin と tcm のコマンド ライン ツールを実行するには、次の 1 種類のグループのメンバーである必要があります: チーム プロジェクトの [Team Foundation 管理者]、[プロジェクト コレクション管理者]、または [プロジェクト管理者]。

• アクセス許可を付与するには、変更するグループのレベルの管理グループのメンバーである必要があります。たとえば、グループまたはユーザーのアクセス許可をチーム プロジェクトのコレクション レベルで変更する場合は、そのコレクションの [プロジェクト コレクション管理者] グループのメンバーであるか、[コレクションレベル情報の編集] アクセス許可が [許可] に設定されている必要があります。

  詳細については、「Team Foundation Server のアクセス許可」を参照してください。

1.名前の変更のシステム フィールド

一部のシステム フィールドの表示名が Visual Studio Team Foundation Server 2010で名前が変更されたため、手動でチーム プロジェクト コレクションのこれらのフィールドの名前を変更する必要があります。名前が変更されたシステム フィールドには、System.AreaID、System.IterationID、System.HyperLinkCount、System.ExternalLinkCount および System.AttachedFileCount があります。

には、アップグレードされた Team Foundation Serverで定義されている各チーム プロジェクト コレクションに対してこのタスクを実行します。

1. Visual Studio 2012 または 2012 をインストール チーム エクスプローラー 開き、入力して、コマンド プロンプト ウィンドウを:

   cd %programfiles%\Microsoft Visual Studio 11.0\Common7\IDE
   

   64 ビット版の Windows で、%programfiles% を %programfiles(x86)% に置き換えます。

2. 次のコマンドのそれぞれが、データを入力し、表示されている次に [ENTER] のキーを選択します。引数の代わりにします。

   witadmin changefield /collection:CollectionURL /n:System.AreaId /name:"Area Id"
   witadmin changefield /collection:CollectionURL /n:System.AttachedFileCount /name:"Attached File Count"
   witadmin changefield /collection:CollectionURL /n:System.ExternalLinkCount /name:"External Link Count"
   witadmin changefield /collection:CollectionURL /n:System.HyperLinkCount /name:"Hyperlink Count"
   witadmin changefield /collection:CollectionURL /n:System.RelatedLinkCount /name:"Related Link Count"
   

   [コレクションの URL]の場合、このファイル形式を使用する: たとえば、http://ServerName:Port/VirtualDirectoryName/CollectionName: http://srvalm:8080/tfs/DefaultCollection。

   ページのトップへ

2.(のみ)、シナリオの作業項目の種類の名前を変更します。

この変更を行う必要があると、アジャイル プロセス テンプレートに、以降の更新に準拠するように、ユーザー ストーリーに、シナリオの作業項目の種類の名前を変更する必要があります。カスタマイズの量を最小限にする。

[!メモ]

もちろん、シナリオの作業項目の種類の名前を変更すると、シナリオの作業項目の種類を参照する既存のクエリおよびレポートを更新する必要があります。ただし、スキーマの変更に Team Foundation Server 2010 へのアップグレード、既存またはアップグレード前のレポートを使用したデータ ウェアハウスに新しいスキーマを使用するように書き直す必要があるようになります。" "を参照してください。Team Foundation Server 2010 へのアップグレード後のレポートを検索できます。

を、更新する各チーム プロジェクトに対してこのタスクを実行します。

• 入力し、表示されている次に [ENTER] のキーを選択します。引数で現在のデータを置き換えてするには、次のコマンドが。

  witadmin renamewitd /collection:CollectionURL /p:projectName /n:Scenario /new:"User Story"
  

  ヒント
  スペースが含まれる場合、パラメーターを引用符で囲みます。たとえば、プロジェクトの名前に空白が含まれている場合、/p:"My Project X" を指定します。

ページのトップへ

3.MSF プロセス テンプレートの最新版をダウンロードします。

「プロセス テンプレートの最新バージョンのダウンロード」を参照してください。

ヒント
既定のプロセス テンプレートの最新バージョンにアクセスするには、Team Foundation Serverの最新の日付は回の更新プログラムをインストールします。重要な更新プログラムは最新の年は回更新の複数の作業項目の種類のワークフローを試みました。これらの変更は、以前のワークフローの状態に戻す解決済みまたは終了状態に誤ってかんばんの板やタスクのボードの作業項目をドラッグすると後方の遷移をように、コントロールをドラッグできます。サポートします。 Microsoft ダウンロード Web サイトからのアップグレードを取得する場合: Microsoft Visual Studio Team Foundation Server 2012 の配列で回の更新[.]

ページのトップへ

4.リンクの種類をインポート

リンクの種類、タスク 3.でダウンロードしたプロセス テンプレートの LinkTypes フォルダーにある SharedSteps および TestedBy をインポートします。

には、アップグレードされた Team Foundation Serverで定義されている各チーム プロジェクト コレクションに対してこのタスクを実行します。

• 入力し、表示されている次に [ENTER] のキーを選択します。引数で現在のデータを置き換えてにする次の 2 個のコマンドが。

  witadmin importlinktype /collection:CollectionURL /f:"DirectoryPath\TestedBy.xml"
  witadmin importlinktype /collection:CollectionURL /f:"DirectoryPath\SharedStep.xml"
  

  DirectoryPath には、ダウンロードしたプロセス テンプレートの LinkTypes フォルダーの場所を指定します。ディレクトリ パスはこの構造に従う必要があります: [ドライブ]: \のMSFTemplateFolderの\WorkItem Tracking\LinkTypes。

  ページのトップへ

5.(省略可能) 作業項目の種類の最新バージョンにカスタマイズを適用します。

の次の作業項目の種類をカスタマイズしている場合は、カスタマイズを使用してこれらの型の最新バージョンを更新する必要があります。次の表は、の最新バージョンで削除され、プロセス テンプレートを追加されるフィールドを示します。

アジャイル作業項目の種類

作業項目の種類	削除されたフィールド	追加されたフィールド
バグ	懸案事項 (Microsoft.VSTS.Common.Issue) ランク (Microsoft.VSTS.Common.Rank)、スタック順位に置き換えられます。 テスト名 (Microsoft.VSTS.Test.TestName) テスト ID (Microsoft.VSTS.Test.TestId) テスト パス (Microsoft.VSTS.Test.TestPath) トリアージ (Microsoft.VSTS.Common.Triage)	Repro をステップ オーバーします (Microsoft.VSTS.TCM.ReproSteps) 重要度 (Microsoft.VSTS.Common.Severity) スタック順位 (Microsoft.VSTS.Common.StackRank) システム情報 (Microsoft.VSTS.TCM.SystemInfo)
タスク	基準作業 (Microsoft.VSTS.Scheduling.BaselineWork)、最初の見積もりに置き換えられる アクティビティに置き換えられる領域 (Microsoft.VSTS.Common.Discipline) 終了基準 (Microsoft.VSTS.Common.ExitCriteria) 懸案事項 (Microsoft.VSTS.Common.Issue) ランク (Microsoft.VSTS.Common.Rank)、スタック順位に置き換えられます。 タスク階層 (Microsoft.VSTS.Scheduling.TaskHierarchy)	アクティビティ (Microsoft.VSTS.Common.Activity) 最初の見積もり (Microsoft.VSTS.Scheduling.OriginalEstimate) スタック順位 (Microsoft.VSTS.Common.StackRank)
ユーザー ストーリー (前に Scenario 示します)	終了基準 (Microsoft.VSTS.Common.ExitCriteria) 懸案事項 (Microsoft.VSTS.Common.Issue) Microsoft.VSTS.Common.RoughOrderOfMagnitude (大まかな桁)、ストーリー ポイントに置き換えられます	リスク (Microsoft.VSTS.Common.Risk) スタック順位 (Microsoft.VSTS.Common.StackRank) ストーリー ポイント (Microsoft.VSTS.Scheduling.StoryPoints)

CMMI 作業項目の種類

作業項目の種類	削除されたフィールド	追加されたフィールド
バグ	基準作業 (Microsoft.VSTS.Scheduling.BaselineWork)、最初の見積もりに置き換えられる 見積もり (Microsoft.VSTS.CMMI.Estimate) 懸案事項 (Microsoft.VSTS.Common.Issue) ランク (Microsoft.VSTS.Common.Rank)、スタック順位に置き換えられます。 再生する手順 (Microsoft.VSTS.CMMI.StepsToReproduce)、再生する手順を置き換えます テスト名 (Microsoft.VSTS.Test.TestName) テスト ID (Microsoft.VSTS.Test.TestId) テスト パス (Microsoft.VSTS.Test.TestPath)	最初の見積もり (Microsoft.VSTS.Scheduling.OriginalEstimate) 重要度 (Microsoft.VSTS.Common.Severity) スタック順位 (Microsoft.VSTS.Common.StackRank) システム情報 (Microsoft.VSTS.TCM.SystemInfo) Repro をステップ オーバーします (Microsoft.VSTS.TCM.ReproSteps)
タスク	基準作業 (Microsoft.VSTS.Scheduling.BaselineWork)、最初の見積もりに置き換えられる 見積もり (Microsoft.VSTS.CMMI.Estimate) 終了基準 (Microsoft.VSTS.Common.ExitCriteria) 懸案事項 (Microsoft.VSTS.Common.Issue) ランク (Microsoft.VSTS.Common.Rank)、スタック順位に置き換えられます。 タスク階層 (Microsoft.VSTS.Scheduling.TaskHierarchy) テスト名 (Microsoft.VSTS.Test.TestName) テスト ID (Microsoft.VSTS.Test.TestId) テスト パス (Microsoft.VSTS.Test.TestPath)	最初の見積もり (Microsoft.VSTS.Scheduling.OriginalEstimate) スタック順位 (Microsoft.VSTS.Common.StackRank)
必要条件	基準作業 (Microsoft.VSTS.Scheduling.BaselineWork)、最初の見積もりに置き換えられる 実績作業 (Microsoft.VSTS.Scheduling.CompletedWork) 見積もり (Microsoft.VSTS.CMMI.Estimate)、スケジューリング サイズに置き換えられる 終了基準 (Microsoft.VSTS.Common.ExitCriteria) 懸案事項 (Microsoft.VSTS.Common.Issue) ランク (Microsoft.VSTS.Common.Rank)、スタック順位に置き換えられます。 残存作業時間) (Microsoft.VSTS.Scheduling.RemainingWork	最初の見積もり (Microsoft.VSTS.Scheduling.OriginalEstimate) スタック順位 (Microsoft.VSTS.Common.StackRank) スケジューリングのサイズ (Microsoft.VSTS.Scheduling.Size)

、適用されるカスタマイズの種類のワークフローの理由に選択リストへのフィールドの追加または変更、追加、またはその含まれています。これらはプロセス構成およびアジャイル計画ツールで使用するためのワークフロー状態は変更しないでください。ワークフローを変更する必要がある場合は、更新を変更の完了、ここで説明する metastate のマッピングに関するガイダンスに従う後には: プロセス構成を使用したバックログ ページおよびボード ページのカスタマイズ。

プロセス テンプレートで定義されているそのほかの作業項目の種類、および最新バージョンに更新する場合は、使用している場合は、それらの場合と同様に対してカスタマイズを適用します。また、テスト ケースを追跡するために使用するカスタムの作業項目の種類を定義する場合、その型から最新のプロセス テンプレートに用意されているテスト ケースの作業項目の種類をカスタマイズを適用する必要があります。

これらのプロセス テンプレートで提供するアーティファクトの操作についてさらに詳しく学習するには、次のトピックを参照:

• Visual Studio ALM のアジャイル プロセス テンプレート (v6.0)

• Visual Studio ALM の CMMI プロセス テンプレート (v6.0)

ページのトップへ

6.作業項目の種類をインポート

使用中のプロセス テンプレートに基づいて、作業項目の種類をインポートします。

• アジャイル: バグ、タスク、ユーザー ストーリー、テスト ケース、共有ステップ、コード レビューの要求、コード レビューの応答、フィードバックの要求、フィードバックの応答

• CMMI: バグ、要件、タスク、テスト ケース、共有ステップ、コード レビューの要求、コード レビューの応答、フィードバックの要求、フィードバックの応答

を、更新する各チーム プロジェクトに対してこのタスクを実行します。

• 各作業項目の種類で次のコマンドを入力して、対象のデータのインポートは、次に示す [ENTER] のキーを必要とする引数の代わりに使用するオプション。

  witadmin importwitd /collection:CollectionURL /p:projectName /f:"DirectoryPath\WITName"
  

  ヒント
  XML ファイルの名前と作業項目の種類のない表示名を指定します。たとえば、コード レビューの要求の作業項目の種類に対して CodeReviewRequest.xml を指定します。

  DirectoryPath には、ダウンロードしたプロセス テンプレートの TypeDefinitions フォルダーのディレクトリの場所を指定します。ディレクトリ パスはこの構造に従う必要があります: [ドライブ]: \のMSFTemplateFolderの\作業 Tracking\TypeDefinitions。

• (省略可能) 作業項目の種類がチーム エクスプローラーまたは Team Web Access を開くことによってアクセスできることを確認します。キャッシュを更新します。 変更を確認できない場合がある場合があります。

ページのトップへ

7.カテゴリ ファイルをインポートする

ダウンロードしたプロセス テンプレートの WorkItem Tracking フォルダーにあるカテゴリ ファイルをインポートします。作業項目の種類のカテゴリのサポートの高度なグループ。詳細については、「作業項目の種類のカテゴリをグループ化するカテゴリの定義」を参照してください。

• コマンド プロンプト ウィンドウで入力し、表示されている次に [ENTER] のキーを選択します。引数で現在のデータを置き換えてするには、次のコマンドが。

  witadmin importcategories /collection:CollectionURL /p:projectName /f:"DirectoryPath\categories.xml"
  

  [DirectoryPath]では、ダウンロードしたプロセス テンプレートの作業項目トラッキング フォルダーのパスを指定します。ディレクトリ パスはこの構造に従う必要があります: [ドライブ]: \のMSFTemplateFolderの\WorkItem トラッキング。

ページのトップへ

8.プロセスの構成ファイルのインポート

プロセスの構成ファイルは、バックログを介して使用できるレイアウトと機能を判断し、Team System Web Accessのページに乗ります。これらのページを使用するには、というシーケンスのプロセスの構成ファイルをインポートする必要があります

• 構成プロセスの定義ファイルを一つずつ、インポート、次に示す [Enter] のキーを入力します。引数で現在のデータを置き換えてにする次の 2 個のコマンドを選択する。

  witadmin importcommonprocessconfig /collection:CollectionURL /p:" ProjectName" /f:"DirectoryPath\CommonConfiguration.xml"
  witadmin importagileprocessconfig /collection:CollectionURL /p:" projectName" /f:"DirectoryPath\AgileConfiguration.xml"
  

  [DirectoryPath]では、ダウンロードしたプロセス テンプレートのプロセス フォルダーのパスを指定します。ディレクトリ パスはこの構造に従う必要があります: [ドライブ]: \のMSFTemplateFolderの\WorkItem Tracking\Process。

ページのトップへ

9.新しい機能へのアクセスを確認します。

使用可能な新機能の検証で提供されるタスクを実行します。

[!メモ]

ここで説明したように、アジャイル チーム プロジェクトのワークフローを更新するために追加の手順を実行する必要はありません: アジャイル チーム プロジェクトのワークフローの更新。このトピックの手順に従うと、これらの変更を既に適用されます。

ページのトップへ

Microsoft テスト マネージャーとやり取りする追加のタスク

テスト マネージャーとやり取りするために必要な更新を完了するには、次のタスクを実行します。

1.Microsoft テスト マネージャーで作成するバグの種類を指定します。

テスト チーム メンバーが Test Manager を使用するときに、コード障害またはバグを追跡する作業項目の自動作成をサポートするには、既存のチーム プロジェクトで使用されるバグの種類を指定する必要があります。tcm bugfieldmapping コマンドは、チーム プロジェクトへのマッピング ファイルのインポートとエクスポートをサポートしています。マッピング ファイルは、作成する作業項目と Test Managerが格納された 3 種類のデータ フィールドの型を定義します。これら 3 つのフィールドは、再現可能な手順、システム情報、および障害が検出されたビルドです。テスト担当者は、テストを実行して障害を検出すると、これらの 3 つのフィールドが自動的に読み込まれるバグを作成できます。

1. メモ帳またはテキスト エディターを開き、次のコードをファイルにコピーします。

   <?xml version="1.0" encoding="utf-16"?
   <BugFilerMappings workitemtypetocreate="Bug">
      <ReproSteps>Microsoft.VSTS.TCM.ReproSteps</ReproSteps>
      <SystemInformation>Microsoft.VSTS.TCM.SystemInfo</SystemInformation>
      <BuildFoundIn>Microsoft.VSTS.Build.FoundIn</BuildFoundIn>
   </BugFilerMappings>
   

   [!メモ]

   コード障害の作成に使用する作業項目の種類が "Bug" 以外にラベル付けされている場合は、上の例の "Bug" を作業項目の種類の名前に置き換えます。

2. ファイルを bugfieldmappings.xml という名前で保存します。

3. コマンド プロンプト ウィンドウで入力し、表示されている次に [ENTER] のキーを選択します。引数で現在のデータを置き換えてするには、次のコマンドが。

   tcm bugfieldmapping /import /mappingfile:"DirectoryPath\bugfieldmappings.xml" /collection:CollectionURL /teamproject:projectName
   

   [DirectoryPath]では、bugfieldmappings.xml ファイルを保存したフォルダーを指定します。

   詳細については、「Microsoft テスト マネージャーを使用して保存するバグの種類の指定」を参照してください。

ページのトップへ

2.テスト チーム メンバーに付与するアクセス許可

テスト環境とテスト構成の管理、テストの実行の作成と表示、およびその他のタスクの実行を担当するテスト チーム メンバーにはアクセス許可を付与する必要があります。

次の表で、テスト機能へのアクセスを制御し、テストに関してチーム プロジェクトとのやり取りをサポートするアクセス許可について説明します。また、MSF バージョン 5.0 のプロセス テンプレートで行った既定の割り当て、および手動のテスト担当者とテスト リーダーに付与する推奨のアクセス許可も示します。

Permission	説明	スコープ	読み取りユーザー	貢献者	ビルダー	手動テスト担当者 (推奨)	テスト リーダー (推奨)
プロジェクトレベル情報を表示します	プロジェクト レベルのグループのメンバーシップ、およびそれらのメンバーのアクセス許可を参照できます。	プロジェクト レベル
テストの実行を表示する	このノードのテスト計画を参照できます。	プロジェクト レベル
テストの実行を作成	テスト結果を追加および削除したり、チーム プロジェクトのテストの実行を追加または変更したりできます。	プロジェクト レベル
テスト構成の管理	チーム プロジェクトのテスト構成を作成および削除できます。	プロジェクト レベル
テスト環境の管理	チーム プロジェクトのテスト環境を作成および削除できます。	プロジェクト レベル
テストの実行を削除します	チーム プロジェクトのスケジュールされたテストを削除できます。	プロジェクト レベル
このノードを表示します	区分ノードのセキュリティ設定を参照できます。	区分ノード
テスト計画の管理	区分ノードに割り当てられる作業項目を作成および編集できます。テスト計画が実行されていない場合は、削除することもできます。	区分ノード
テスト コントローラーの管理	チーム プロジェクト コレクションのテスト コントローラーを登録および登録解除できます。	プロジェクト コレクション

特定のスコープ区分については、次の手順に従ってアクセス許可を付与できます。

• Team System Web Accessの管理]ページからプロジェクト レベルのアクセス許可または区分ノードのアクセス許可を設定できます。「アクセス許可の管理」および「区分およびイテレーションの作成および修正」を参照してください。

• [Team, Team Project Collection Settings, Security] を Team Foundation、の管理コンソールを開いて使用するか選択することによって、または TFSSecurity と tf のコマンド ライン ツールを使用して チーム エクスプローラー からプロジェクト コレクションのアクセス許可を設定できます。詳細については、「Collection-Level Groups」を参照してください。

詳細については、「グループまたはユーザーのアクセス許可の変更」を参照してください。

ページのトップへ

3.スタートアップ Microsoft テスト マネージャー

このトピックで既に説明したアップグレード タスクを完了した後は、Microsoft Test Manager を開始してプロジェクトに接続し、テスト工数の計画を開始することができます。詳細については、「アプリケーションのテスト」を参照してください。

ページのトップへ

TFS をアップグレードするときに行われた変更に関する追加情報

Visual Studio Team System 2008 Team Foundation Server から TFS 2012 にアップグレードすると、TFS 2010 および 2012 では、TFS 両方に対して行われた更新を受け取ります。TFS 2010 のリリースで行われたいくつかのアーキテクチャ変更がありました。Visual Studio Team System 2008 Team Foundation Serverから TFS の最新バージョンにアップグレードすることによって加えられた変更の詳細については、次のリソースを参照:

• Team Foundation Server 2010 の主要な概念 (ブログの投稿)

• 新しい機能にアクセス アップグレードされたチーム プロジェクトの更新 (ALM の 2010 年の文書と)

• Team Foundation Server 2010 へのアップグレード後のレポートを検索できます。 (ALM の 2010 年の文書と)

• Analysis Services キューブのスキーマに対する変更内容および追加内容 (ALM の 2010 年の文書と)

• Team Foundation Server のアップグレード中にチーム プロジェクトと既定のプロセス テンプレートに加えた変更 (ALM の 2012 年の文書と)

参照

概念

アップグレードされたチーム プロジェクトの更新による新機能の利用

その他の技術情報

witAdmin: 作業項目を追跡するためのオブジェクトのカスタマイズおよび管理