次の方法で共有

移行用のサーバー環境を検証して準備する

  • [アーティクル]

検証には、アップグレードされた Azure DevOps Server 環境を移行用に準備する必要があります。 この記事では、一般的な問題のトラブルシューティングに役立ちます。 エラーがなく、すべての検証チェックに合格した場合は、チーム プロジェクト コレクションの準備が整い、次のフェーズに進むことができます。 すべてのチェックが渡されていない場合は、ログ ファイルを調べてエラーを見つけます。

移行の 7 つのステージの強調表示された検証ステージの図。

前提条件

最新 のデータ移行ツールをダウンロードします。

プロセスの検証の種類について説明します

検証中に、データ移行ツールによって、各プロジェクトのターゲット プロセス モデルが決定されます。 次の 2 つのプロセス モデルのいずれかが、コレクション内の各プロジェクトに自動的に割り当てられます。

  • 継承されたプロセス モデル: プロジェクトがアジャイル、スクラム、または機能成熟度モデル統合 (CMMI) プロセス テンプレートを使用して作成され、カスタマイズされなかった場合。
  • ホストされた XML プロセス モデル: プロジェクト プロセスがカスタマイズされたように見える場合。 カスタマイズされたプロセスには、ユーザー設定フィールド、作業項目の種類、またはその他の種類のカスタマイズが含まれます。

Hosted XML プロセスがターゲット プロセス モデルの場合、データ移行ツールはカスタマイズを移行できるかどうかを検証します。 データ移行ツールでは、検証中に次の 2 つのファイルが生成されます。

  • DataMigrationTool.log: コレクション内で検出されたプロセス検証エラーのセットが含まれています。 移行を続行するために検出されたすべてのプロセス エラーを修正します。
  • TryMatchOobProcesses.log: ターゲット プロセス モデルである継承またはホストされた XML の各プロジェクトの一覧です。 Hosted XML プロセス モデルをターゲットに設定されているプロジェクトの場合は、それらがカスタマイズされていると見なされる理由について説明します。 これらのエラーを修正する必要はありませんが、継承プロセス モデルに移行する場合のガイダンスが提供されます。 コレクションが移行されたら、プロジェクトを継承プロセス モデルに移行できます。

チーム プロジェクト コレクションを検証する

各チーム プロジェクト コレクションは独自の SQL データベースに対応するため、検証プロセスでは、次のようなコレクションのさまざまな側面を調べます。

  • コレクション データベースのサイズ
  • SQL データベースの照合順序
  • コレクション内のユーザーの ID
  • テンプレートのカスタマイズ (プロセス)

検証を開始するには、移行ツールを使用します。 Azure DevOps Server 環境のいずれかのアプリケーション層 (AT) サーバーから移行ツールを実行することをお勧めします。

特定のコマンド ライン オプションについては、次のコマンドを使用してヘルプ テキストを要求します。

	Migrator validate /help

検証を開始する最も一般的な方法は、チーム プロジェクト コレクションの URL を次の構造で指定することです。

	Migrator validate /collection:http://localhost:8080/tfs/DefaultCollection

検証の警告とエラーを表示する

移行ツールが完了すると、コマンド プロンプト画面にログ ファイルと結果が表示されます。 エラーが発生せず、すべての検証チェックが成功した場合、チーム プロジェクト コレクションは次のフェーズに向けて準備が整います。 検証チェックが失敗した場合は、ログ ファイルを確認してエラーを特定し、それらに対処します。

検証チェックMigrator.logに関する重要な詳細が含まれており、カスタマイズを維持するのに役立つファイルに焦点を当てます。 他のファイルは、名前に基づいて特定の検証エラーに対応します。 "Validation - Starting validation of project 1" という文字列を検索します。各プロジェクトが検証されます。 すべてのプロジェクトをスキャンし、プレフィックスが含まれる任意の行を検索します。 [Error...

また、 TryMatchOobProcesses.log Out-of-Box (OOB) プロセス (アジャイル、スクラム、CMMI など) を使用するプロジェクトに関連するエラーも一覧表示されます。 プロジェクトがカスタマイズなしで OOB プロセスを使用する場合、プロジェクトは継承されたモデルに含まれます。 重要なのは、このファイル内のエラーによって移行プロセスが妨げられることはありません。

データ移行ツールによって生成されたDataMigrationTool.log ファイルのスクリーンショット。

検証エラーの一覧については、「検証エラーの解決」を参照してください。 検証エラーごとに、エラー番号、説明、および解決するメソッドを指定しました。 検証チェックログには、さまざまなエラーの種類が表示される場合があります。 発生したエラーを解決するために、トレーニング済みの DevOps パートナー、Microsoft コンサルティング サービス、または Microsoft Premier サポートに支援を求めます。

プロセス テンプレートのエラーを解決する

見つかる主なエラーは、プロセス テンプレートの問題です。 これらの問題は、Azure DevOps Server の最新機能を組み込まない古いチーム プロジェクト、または Azure DevOps Services によるサポートされていないカスタマイズに起因します。 ただし、Azure DevOps Services ではさまざまなカスタマイズがサポートされており、検証では、解決の事前割り当てが必要なユーザーにのみフラグが設定されます。 データ移行ツールは、Azure DevOps Services の互換性のためにテンプレートの包括的なチェックを実行しますが、一部の変更が必要になる場合があります。

  • カスタマイズされたプロセス テンプレートまたは古いテンプレートでは、移行中にプロセス検証エラーが発生する可能性があります。
  • OOB アジャイル、スクラム、または CMMI プロセスを使用する場合は、エラーをTryMatchOobProcesses.logチェックします。 エラーのないプロジェクトは OOB プロセスにマップされます。
  • 一部のカスタマイズは、Azure DevOps Services では機能しません。 サポートされているカスタマイズの一覧を確認します。
  • 古いテンプレートを使用するプロジェクトの場合は、機能の構成ウィザードを実行して、最近の機能でテンプレートを更新し、エラー数を減らします。
  • プロセス エラーを修正するコンピューターで使用できることを確認 witadmin します。 プロセス テンプレートに変更を加えるためには不可欠です。

プロセス エラーを解決するには、次のツールを検討してください。

  • Visual Studio のインストールに含まれるwitadmin.exeコマンドライン ツールを利用します。 これらのエラーに対処するための詳細な技術ドキュメントについては、このリンクを参照してください。
  • ドキュメントに記載されていない移行ツール コマンドを使用して、各チーム プロジェクトのプロセス テンプレートのエクスポートを自動化します。Migrator は /collection:http://localhost:8080/tfs/DefaultCollection /SaveProcesses を検証します。
  • GitHub の TFS チーム プロジェクト マネージャー (リンク) を調べる。 これにより、すぐに使用できるテンプレートを含め、チーム プロジェクトを既知のプロセス テンプレートと比較できます。

エラーを修正するには、XML 構文を変更し、変更をプロジェクトに適用します。

ヒント

TFS Power Tools を使用するのではなく、XML を手動で変更することをお勧めします。

プロジェクトからプロセス テンプレートを取得するには、Data Migration Tool コマンドを /SaveProcesses 実行するときにパラメーターを追加します。

Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region} /SaveProcesses

このコマンドは、プロジェクトから XML を抽出し、ログと同じフォルダーに配置します。 zip ファイルをローカル コンピューターに抽出して、ファイルを編集できるようにします。

次に、XML を修正します。 DataMigrationTool.log ファイルのログを使用して、各プロジェクトのエラーを特定します。

データ移行ツールによって生成されたプロセス ログ ファイルのスクリーンショット。

一部のエラーでは、コマンドを使用する必要があります witadmin changefield 。 フィールド名の変更は最も一般的な例です。 時間を節約するには、witadmin changefield コマンドを実行してから、データ移行ツールを再実行することをお勧めします。 これにより、修正された名前で XML が再エクスポートされます。 それ以外の場合は、XML 構文のフィールドも手動で修正します。

修正を行ったら、変更を Azure DevOps Server に適用し直します。 行った変更に応じて、1 つ以上の witadmin コマンドを実行する必要があります。 このプロセスを自動化するための PowerShell スクリプトを作成しました。 スクリプトには、プロセス全体を確認するために必要なすべての witadmin コマンドが含まれています。

スクリプトはプロセス カスタマイズ スクリプトで取得できます。 import/ConformProject.ps1 スクリプトを使用します。

.\conformproject.ps1 "<collection url>" "<project name>" "<process template folder>"

スクリプトが完了したら、データ移行ツールを再実行してコレクションを検証します。 データ移行ツールで検証エラーが生成されないまで、手順 1 から 3 に従います。

PowerShell の準拠プロジェクト プロセスのスクリーンショット。

ヒント

XML と witadmin を初めて使用する場合は、一度に 1 つの修正を行ってから準拠することをお勧めします。 すべてのエラーが解決されるまで、このループを続行します。

システム プロセスへの更新

以前のバージョンの Azure DevOps Server を使い始めた場合、プロジェクトでは古いプロセス テンプレートが使用されている可能性があります。 これらのプロジェクトが機能の構成ウィザードを使用して更新されなかった場合、データ移行ツールはプロセス エラーを検出します。 まれに、ウィザードでも古いプロセス関連の問題が解決されないことがあります。

次のサンプル エラー メッセージの一部が表示される場合があります。

Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element PortfolioBacklog is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element BugWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackRequestWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402571: Required element FeedbackResponseWorkItems is missing from Process Configuration.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Team.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField RemainingWork.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Order.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Effort.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField Activity.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationStartInformation.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationLaunchInstructions.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF402574: ProcessConfiguration doesn't specify required TypeField ApplicationType.
Invalid process template: WorkItem Tracking\Process\ProcessConfiguration.xml:: TF400572: The Project Process Settings must be configured for this feature to be used.

プロジェクト (追加されたフィールド、作業項目の種類など) をカスタマイズしなかった場合、これらのエラーの修正は簡単です。 ただし、プロセスをカスタマイズした場合、このアプローチでは十分ではありません。 カスタマイズが上書きされないようにするには、プロセス テンプレートを手動で調整する必要があります。

プロセスを調整するには、プロジェクトごとに次の手順を実行します。

  1. プロジェクトが開始した最初のプロセス (スクラム、アジャイル、または CMMI) を特定します。
  2. GitHub のプロセス カスタマイズ スクリプトにアクセスし、リポジトリをダウンロードします。
  3. 移行フォルダー内の内容に注目します。
  4. 次 ConformProject.ps1 のスクリプトを使用して、選択したプロジェクトをアジャイル システム プロセスに合わせます。 このアクションにより、プロジェクト全体がアジャイルに更新されます。
.\ConformProject.ps1 "<collection url>" "<project name>" "c:\process-customization-scripts\import\agile"

一般的な検証エラー

VS402841: 作業項目の種類のフィールド X には、syncnamechanges=false がありますが、ID フィールドにするルールがあります。 ID フィールドには syncnamechanges=true が必要です。 プロセス テンプレートを更新して、この変更を含めてください。

Azure DevOps Services では、すべての ID フィールドに属性が必要になるようにルールを syncnamechanges=true 追加しました。 Azure DevOps Server では、ルールは適用されません。 そのため、データ移行ツールはこれを問題として識別します。 オンプレミスの Azure DevOps Server でこの変更を行っても、問題は発生しません。

witadmin changefield コマンドを実行します。 コマンドの構文は次の例のようになります。

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /syncnamechanges:true

witadmin changefield コマンドの詳細については、「作業項目の管理」フィールドを参照してください。

TF402556: フィールド System.IterationId を適切に定義するには、それにイテレーション ID という名前を付け、その型を整数に設定する必要があります。

このエラーは、多くの場合、古いプロセス テンプレートに関連付けられています。 それに対処するには、各プロジェクトの機能の 構成ウィザード を実行します。 または、次のコマンドを実行してプロセスを自動化することもできます。

witadmin changefield /collection:http://AdventureWorksServer:8080/tfs/DefaultCollection /n:fieldname /name:newname

TF402571: 必須要素 BugWorkItems がプロセス構成にありません。

このエラーは、プロセスがしばらく更新されなかった場合に一般的に発生します。 これを修正するには、各プロジェクトの機能の 構成ウィザードを実行します 。

TF402564: XX グローバル リストを定義しました。 許可されているのは 64 個のみです

Azure DevOps Services では、64 個のグローバル リストがネイティブでサポートされています。 このエラーは通常、多数のビルド パイプラインがある場合に発生します。これは、新しい各パイプラインによって名前が付けられた Builds - TeamProjectNameグローバル リストが作成されるためです。 このエラーを解決するには、古いグローバル リストを削除します。

検証チェックを繰り返す

各イテレーションで、エラーに対処し、検証ログ ファイルで示されているように、エラーを解決するために検証チェックを実行します。 すべてのエラーが修正され、コレクションの検証チェックが成功したことを確認するメッセージが表示されるまで、このサイクルで保持します。

次のステップ

テスト実行の準備