Azure DevOps Services に Team Foundation Server の展開をリファクターする

注意

Team Foundation Server (TFS) 2019 のリリースでは、TFS の名前が Azure DevOps Server に変更されました。 この記事の大部分では、以前のバージョンの TFS の実際の製品名と記事の意図に合わせて、今も Team Foundation Server に言及します。 たとえば、Team Foundation Server 移行ツールは、Azure DevOps Server 移行ツールと呼ばれるようになりました。

この記事では、架空の会社である Contoso がオンプレミスの Visual Studio Team Foundation Server のデプロイを、Azure の Azure DevOps Services に移行することでリファクターする方法について説明します。 このシナリオでは、Contoso の開発チームは、過去 5 年間、チームのコラボレーションとソース管理に Team Foundation Server を使用してきました。 現在、チームは、クラウドベースのソリューションに移行して、開発やテストの作業とソース管理を行いたいと考えています。 Contoso チームが Azure DevOps Services モデルに移行し、新しいクラウドネイティブ アプリケーションを開発する際に、Azure DevOps Services は重要な役割を果たします。

ビジネス ドライバー

Contoso の IT リーダーシップ チームは、ビジネス パートナーと密接に協力して将来の目標を明らかにしました。 パートナーは、開発ツールやテクノロジにあまり関心がありませんが、チームはこれらの点を把握しています。

  • ソフトウェア: 中心の業務にかかわらず、Contoso を含め、すべての企業は基本的にソフトウェア企業になりました。 企業の上層部は、Contoso の IT 部門がユーザーの新しい業務慣行や顧客の新しいエクスペリエンスを利用して業務を改善する方法に関心を持っています。
  • 効率化: Contoso はプロセスを合理化し、開発者とユーザーにとって不要な手順を取り除きたいと考えています。 そうすることで、顧客の要件により効率的に対応できるようになります。 Contoso の IT 部門には、時間やお金を無駄にせず、迅速に行動できることが求められています。
  • 機敏性: Contoso の IT 部門は、グローバル経済における成功を実現するために、ビジネス ニーズに対しての対応力を向上させる必要があります。 市場の変化に対して、より迅速に対応できる必要があり、ビジネスの阻害要因となってはいけません。

移行の目標

Contoso クラウド チームには、Azure DevOps Services への移行に関して、次の目標があります。

  • ツールを使用し、少ない手動プロセスでデータをクラウドに移行する。
  • 過去 1 年間の作業項目データと履歴を移行する。
  • 現在のすべてのシステム割り当てを維持し、新しいユーザー名とパスワードを作成しない。
  • ソース管理については、Team Foundation バージョン管理 (TFVC) から Git に移行する。
  • Git への切り替えは、コードベースの転換時にすべての作業が中止されるダウンタイム中に行う。 Git への切り替えは、ソース コードの最新バージョンのみをインポートするチップ移行です。 移行後は、最新のメイン ブランチ履歴のみが利用可能になります。
  • Azure DevOps Services への移行後に Team Foundation Server へのアクセスを保持し、完全な移行を実行する前にテストを実行する。
  • プロジェクト数が少ないコレクションから開始する。
  • Team Foundation Server コレクションは Azure DevOps Services 組織と 1 対 1 の関係にあるため、URL は複数になる。 このモデルはコード ベースとプロジェクトの分離という現在のモデルと一致します。

提案されたアーキテクチャ

  • Contoso は Team Foundation Server プロジェクトをクラウドに移行します。今後は、プロジェクトやソース管理をオンプレミスではホストしません。
  • Team Foundation Server は Azure DevOps Services に移行されます。
  • 現在、Contoso には ContosoDev という名前の Team Foundation Server コレクションが 1 つあります。これは contosodevmigration.visualstudio.com という Azure DevOps Services 組織に移行されます。
  • 昨年のプロジェクト、作業項目、バグ、およびイテレーションは、Azure DevOps Services に移行されます。
  • Contoso はその Microsoft Entra インスタンスを利用します。これは、移行計画の開始時に Azure インフラストラクチャをデプロイしたときに設定したものです。

Diagram of the proposed architecture.

移行プロセス

この記事で示す一般的な移行プロセスは次のとおりです。

  1. 最初に、Contoso は Team Foundation Server の実装を、サポートされるレベルまでアップグレードする必要があります。

    Contoso では現在 Team Foundation Server 2017 Update 3 を実行しています。 しかし、データベースの移行を使用するには、最新の更新プログラムが適用された、サポートされているバージョンを実行する必要があります。 アップグレード バージョンとしてサポートされなくなりましたが、この架空の例では、Contoso 管理者チームが Team Foundation Server 2018 Upgrade 3 にアップグレードします。

    重要

    移行でサポートされている Azure DevOps Server (旧称 Team Foundation Services) のバージョンの一覧については、「Azure DevOps Server から Azure DevOps Services にデータを移行する」を参照してください。 アップグレードのサポートについては、「デプロイを最新バージョンの Azure DevOps Server にアップグレードする」を参照し、左上の [バージョン] ドロップダウンで必ずバージョンを選択してください。

    サポートされているバージョンのアップグレードの詳細については、後述の「手順 3: Team Foundation Server コレクションを検証する」セクションでダウンロードする移行ツールに含まれているガイドの「第 3 章: アップグレード」を参照してください。

  2. Team Foundation Server 移行ツールを実行し、そのコレクションを検証します。

  3. 一連の準備ファイルを作成し、テストのために移行のドライ ランを実行します。

  4. 作業項目、バグ、スプリント、コードを含む、完全な移行を実行します。

  5. TFVC から Git へコードを移動します。

Diagram of the Contoso migration process.

前提条件

このシナリオを実行するには、Contoso は次の前提条件を満たす必要があります。

Azure サブスクリプション

Contoso では、「サブスクリプションの管理」の説明に従ってサブスクリプションを設定します。

  • Azure サブスクリプションをお持ちでない場合は、無料アカウントを作成してください。
  • 無料アカウントを作成する場合、サブスクリプションの管理者としてすべてのアクションを実行できます。
  • 既存のサブスクリプションを使用する場合、自分が管理者ではないなら、管理者と協力して自分に所有者または共同作成者のアクセス許可を割り当てます。
  • より詳細なアクセス許可が必要な場合は、ロールベースのアクセス制御を使用した Azure Site Recovery のアクセスの管理に関する記事をご覧ください。

Azure インフラストラクチャ

Contoso は、「移行インフラストラクチャをデプロイする」で説明されているように、Azure インフラストラクチャを設定します。

オンプレミスの Team Foundation Server インスタンス

この架空の例のオンプレミス インスタンスは、Team Foundation Server 2018 Upgrade 3 を稼働しているか、このプロセスの一環としてそちらにアップグレードする必要があります。

シナリオのステップ

Contoso の管理者は、次のようにして移行を完了します。

  • ステップ 1:Azure Storage アカウントを作成する。 このストレージ アカウントは、移行プロセス中に使用されます。
  • 手順 2:Team Foundation Server をアップグレードする。 移行をサポートするバージョンの Azure DevOps Server にデプロイをアップグレードします。
  • ステップ 3:Team Foundation Server コレクションを検証する。 移行の準備として Team Foundation Server コレクションを検証します。
  • 手順 4:移行ファイルを作成する。 Team Foundation Server 移行ツールを使用して移行ファイルを作成します。
  • 手順 5: Azure DevOps Services への移行 準備が完了したので、Contoso の管理者は移行に専念できます。

ステップ 1: Azure Storage アカウントを作成する

  1. Azure portal で、contosodevmigration という名前のストレージ アカウントを作成します。

  2. フェールオーバーに使用するセカンダリ リージョン (米国中部) にアカウントを配置します。 ローカル冗長ストレージには標準アカウントを使用します。

    Screenshot of the **Create storage account** pane.

関連項目:

手順 2:Team Foundation Server をアップグレードする

次の一般的な手順を使用して、Team Foundation Server インスタンスを、移行をサポートするAzure DevOps Server のバージョンにアップグレードします。 いずれの場合も、左上の [バージョン] ドロップダウンで必ずバージョンを選択してください。

  1. デプロイを最新バージョンの Azure DevOps Server にアップグレードする」をご確認ください。
  2. 最新のダウンロードについては、「Azure DevOps Server ダウンロード」を参照してください。
  3. オンプレミスの Azure DevOps の要件を確認します。
  4. リリース ノートをご覧ください。

Contoso 管理者がサーバーを Team Foundation Server 2018 Update 3 にアップグレードするために実行した手順の例を次に示します。

  1. VMware 仮想マシン (VM) 上で実行されている Team Foundation Server インスタンスをバックアップし、VMware のスナップショットを作成します。

    Team Foundation Server のインストーラが開始されます。

    Screenshot of the Getting Started page for upgrading Team Foundation Server.

  2. インストール場所を選択します。 インストーラにはインターネット アクセスが必要です。

    Screenshot of the Team Foundation Server installation site in Visual Studio.

    インストールが完了すると、サーバー構成ウィザードが起動します。

  3. [ようこそ] ページで [次へ] をクリックして続行します。

    Screenshot of the Team Foundation Server 2018 Update 2 configuration wizard.

  4. サーバー構成ウィザードの設定を確認して同意すると、アップグレードが完了します。

    Screenshot of the Team Foundation Server Configuration Wizard upgrade progress pane.

  5. プロジェクト、作業項目、コードを確かめて Team Foundation Server のインストールを確認します。

    Screenshot of the **Product backlog** pane for verifying the Team Foundation Server installation.

    Note

    一部の Team Foundation Server アップグレードでは、アップグレードの完了後に機能の構成ウィザードを実行する必要があります。 詳細については、アップグレード後の機能の構成に関するページを参照してください。

関連項目:

Team Foundation Server のアップグレードに関するページを参照してください。

手順 3:Team Foundation Server コレクションを検証する

Contoso の管理者は、移行前に contosodev コレクション データベースに対して Team Foundation Server 移行ツールを実行して検証します。

  1. Team Foundation Server 移行ツールをダウンロードして解凍します。 ダウンロード ページには、サポートされている 3 つの最新バージョンの移行ツールを含む 3 つの .zip ファイルがあります。 現在実行しているバージョンを確認するには、管理コンソールを参照してください。

    移行時に Contoso 管理者が使用したバージョン情報とダウンロードの選択を次に示します。

    Screenshot of the Team Foundation Server pane for verifying the product version.

  2. プロジェクト コレクションの URL を指定して、検証を実行する移行ツールを実行します。 次に例を示します。

    TfsMigrator validate /collection:http://contosotfs:8080/tfs/ContosoDev

    この例では、移行ツールにエラーが表示されます。

    Screenshot of a validation error in the Team Foundation Server migration tool.

  3. Logs フォルダー内のログ ファイルを見つけます。

    主要な検証ごとにログ ファイルが生成されます。 TfsMigration.log は主要な情報を保持しています。

  4. ログ ファイルで、次の ID 検証エントリを探します。

    Screenshot showing the error found during identity validation.

  5. コマンド ラインに TfsMigrator validate /help と入力します。

  6. プロジェクト コレクションとテナント ドメイン名のパラメーターを含めて検証コマンドをもう一度実行します: TfsMigrator validate /collection:http://contosotfs:8080/tfs/ContosoDev /tenantDomainName:contosomigration.onmicrosoft.com

  7. Microsoft Entra サインイン ウィンドウが表示されたら、Contoso 管理者ユーザーの資格情報を入力します。

    検証に合格すると、移行ツールによって確認されます。

    Screenshot showing that validation has passed.

手順 4:移行ファイルを作成する

検証が完了したので、Contoso の管理者は Team Foundation Server 移行ツールを使用して移行ファイルを作成します。

  1. 移行ツールを使用して prepare コマンドを実行します。

    TfsMigrator prepare /collection:http://contosotfs:8080/tfs/ContosoDev /tenantDomainName:contosomigration.onmicrosoft.com /accountRegion:cus

    prepare コマンドによって、次の処理が行われます。

    • コレクションをスキャンしてすべてのユーザーの一覧を検索し、ID マップ ログ (IdentityMapLog.csv) を作成します。
    • Microsoft Entra ID への接続を準備し、各 ID に一致するものを検索します。
    • 一致する ID を検出し、アクティブとしてマークします。 prepare コマンドでこれが行われるのは、Contoso の管理者が既に Microsoft Entra ID をデプロイし、Microsoft Entra Connect を使用してそれを同期化しているからです。
  2. Microsoft Entra サインイン ウィンドウが表示されたら、Contoso 管理者ユーザーの資格情報を入力します。

    準備が完了すると、インポート ファイルが正常に生成されたことが移行ツールによって報告されます。

    Screenshot of the migration tool, showing that collection validation is successful.

  3. IdentityMapLog.csv ファイルと import.json ファイルの両方がマシン上の新しいフォルダー内に作成されたことを確認します。

    import.json ファイルにはインポート設定が記録されています。 これには、組織名やストレージ アカウントの詳細などの情報が含まれています。 ほとんどのフィールドは自動的に設定されますが、一部のフィールドではユーザー入力が必要です。

  4. import.json ファイルを開き、作成する Azure DevOps Services 組織名 contosodevmigration を追加します。

    この名前の場合、Contoso の Azure DevOps Services の URL は contosodevmigration.visualstudio.com になります。

    Screenshot showing the Azure DevOps Services organization name.

    Note

    組織は移行の開始前に作成しておく必要があります。 これは移行の完了後に変更することができます。

  5. ID ログ マップ ファイルを確認します。そこには、インポート中に Azure DevOps Services に取り込まれるアカウントが示されます。

    • アクティブな ID とは、インポート後に Azure DevOps Services 内のユーザーになる ID のことです。

    • Azure DevOps Services で、これらの ID にライセンスが付与され、移行後に組織のユーザーとして表示されます。

    • これらの ID は、ファイルの Expected Import Status 列で Active とマークされています。 次に例を示します。

      Screenshot of the identity log map file, showing the accounts to be brought into Azure DevOps Services.

手順 5:Azure DevOps Services に移行する

準備が完了したので、Contoso の管理者は移行に専念できます。 移行を実行すると、バージョン管理には TFVC ではなく Git が使用されるようになります。

Contoso の管理者は、開始する前に開発チームと共にダウンタイムのスケジュールを設定します。そうすることで、移行に備えてコレクションをオフラインにするための計画を立てることができます。

次の移行プロセスに従ってください。

  1. コレクションをデタッチする。 インポート中に発生した変更はインポートできないので、インポートが完了するまでは、コレクションをデタッチし、その状態を維持してください。

    Team Foundation Server インスタンスからコレクションをデタッチすると、その ID データのコピーが転送のためにコレクションと共にパッケージ化されます。 インポートの ID 部分を実行するには、このデータが必要です。

    コレクションの ID データは、コレクションがアタッチされ、オンラインのときは Team Foundation Server インスタンスの構成データベース内に保存されます。

  2. バックアップを生成する。 Azure DevOps Services にインポートできるバックアップを生成します。

    データ層アプリケーション コンポーネント パッケージ (DACPAC) は SQL Server の機能で、これを使用すると、データベースの変更を単一のファイルにパッケージ化し、SQL の他のインスタンスにデプロイできます。

    バックアップは、Azure DevOps Services に直接復元し、コレクション データをクラウドに取り込むためのパッケージ化方法として使用できます。 Contoso の管理者は sqlpackage.exe ツールを使用して DACPAC を生成します。 このツールは、SQL Server Data Tools に含まれています。

  3. ストレージにアップロードします。 DACPAC が作成されたら、Azure Storage にアップロードします。

    アップロード後、Shared Access Signature (SAS) が生成され、Team Foundation Server 移行ツールからストレージにアクセスできるようになります。

  4. dry-run インポートを実行します。 DACPAC 設定など、インポート ファイル内の欠けているフィールドに入力します。 完全な移行の前にすべてが正常に機能していることを確認するため、"ドライラン" インポートを実行するよう指定します。

    ドライラン インポートは、コレクションの移行をテストするのに役立ちます。 ドライ ランの有効期間は限られており、設定された期間が経過した後、および運用環境の移行が実行される前に自動的に削除されます。 インポートが完了した後に送信される成功メールには、ドライ ランが削除される時期を Contoso に通知するメモが含まれます。

  5. 運用環境の移行を完了する。 ドライランによる移行が完了したら、import.json ファイルを更新し、インポートを再実行して、最終的な移行を実行します。

コレクションをデタッチする

Contoso の管理者は、コレクションをデタッチする前にローカル SQL Server インスタンスのバックアップを実行し、Team Foundation Server インスタンスの VMware スナップショットを作成します。

  1. Team Foundation Server 管理コンソールで、デタッチするコレクション (ContosoDev) を選択します。

    Screenshot of the **Team Project Collections** section of the Foundation Server Administration Console.

  2. [全般] タブを選択し、[コレクションのデタッチ] を選択します。

    Screenshot of the **Detach Collection** link in the Foundation Server Administration Console.

  3. チーム プロジェクト コレクションのデタッチ ウィザードの [サービス メッセージ] ページで、コレクション内のプロジェクトに接続しようとするユーザー向けのメッセージを入力します。

    Screenshot of the **Servicing Message** pane in the Detach Team Project Collection Wizard.

  4. [デタッチの進行状況] ページで進行状況を監視します。 処理が完了したら、[次へ] を選択します。

    Screenshot of the **Detach Progress** pane in the Detach Team Project Collection Wizard.

  5. [準備チェック] ページでチェックが完了したら、[デタッチ] を選択します。

    Screenshot of the **Readiness Checks** page in the Detach Team Project Collection Wizard.

  6. コレクションが正常にデタッチされたら、[閉じる] を選択します。

    Screenshot of the **Complete** page in the Detach Team Project Collection Wizard.

    コレクションは Team Foundation Server 管理コンソールで参照されなくなります。

DACPAC を生成する

Azure DevOps Services にインポートするためのバックアップ (DACPAC) を Contoso の管理者が作成します。

  • Contoso の管理者は DACPAC の作成に SQL Server Data Tools (SSDT) の sqlpackage.exe ユーティリティを使用します。 SQL Server Data Tools と一緒に sqlpackage.exe の複数のバージョンがインストールされ、120130140 などの名前が付いたフォルダーに配置されます。 適切なバージョンを使用して DACPAC を準備することが重要です。

  • Team Foundation Server 2018 のインポートでは、140 以降のフォルダーの sqlpackage.exe を使用する必要があります。 CONTOSOTFS の場合、このファイルは C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140 にあります。

Contoso の管理者は次のように DACPAC を生成します。

  1. コマンド プロンプトを開き、sqlpackage.exe の場所に移動します。 DACPAC を生成するには、次のコマンドを実行します。

    SqlPackage.exe /sourceconnectionstring:"Data Source=SQLSERVERNAME\INSTANCENAME;Initial Catalog=Tfs_ContosoDev;Integrated Security=True" /targetFile:C:\TFSMigrator\Tfs_ContosoDev.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

    次に例を示します。

    Screenshot of the command prompt, displaying the command for generating the DACPAC.

    次のメッセージが表示されます。

    Screenshot of the command prompt, displaying a message that the database was successfully extracted and saved to a DACPAC file.

  2. DACPAC ファイルのプロパティを確認します。

    Screenshot displaying the DACPAC file properties for verification.

ファイルをストレージにアップロードする

Contoso の管理者が、作成した DACPAC ファイルを Azure Storage アカウントにアップロードします。

  1. Azure Storage Explorer をダウンロードしてインストールします。

  2. Storage Explorer で、サブスクリプションに接続し、移行用に作成したストレージ アカウント (contosodevmigration) を検索して選択します。 新しい BLOB コンテナー azuredevopsmigration を作成します。

    Screenshot of the **Create Blob Container** link in Storage Explorer.

  3. DACPAC ファイルのアップロードについて、[ファイルのアップロード] ペインの [BLOB の種類] ドロップダウン リストから、[ブロック BLOB] を指定します。

    Screenshot of the **Upload files** pane in Storage Explorer.

  4. ファイルのアップロード後、ファイル名を選択し、[SAS の生成] を選択します。 ストレージ アカウントの [BLOB コンテナー] 一覧を展開し、インポート ファイルが含まれているコンテナーを選択して、[Shared Access Signature の取得] を選択します。

    Screenshot of the **Get Shared Access Signature** link in Storage Explorer.

  5. [Shared Access Signature] ページで既定の設定をそのまま使用し、[作成] を選択します。

    これらの設定により、24 時間アクセスが有効になります。

    Screenshot of the **Shared Access Signature** pane in Storage Explorer.

  6. Shared Access Signature の URL をコピーし、Team Foundation Server 移行ツールで使用できるようにします。

    Screenshot of the URL of the shared access signature in Storage Explorer.

Note

許可された期間内に移行が完了する必要があります。完了しない場合、アクセス許可は期限切れになります。 Azure portal からは SAS キーを生成 "しない" でください。 ポータルから生成されたキーは、アカウント スコープであり、インポートには使用できません。

インポート設定を入力する

この記事の初めの方で、Contoso の管理者はインポート仕様ファイル import.json の一部を入力しました。 今回は、残りの設定を追加する必要があります。

import.json ファイルを開き、次のフィールドに入力します。

  • Location: 前に生成された SAS キーの場所を入力します。
  • DACPAC: 先ほどストレージ アカウントにアップロードした DACPAC ファイルの名前を入力します。.dacpac 拡張子を必ず含めてください。
  • ImportType:DryRun」と入力します。

Screenshot of the `import.json` file with the fields filled in.

dry-run による移行を実行する

Contoso の管理者はドライ ラン移行を実行し、すべてが想定どおりに動作していることを確認します。

  1. コマンド プロンプトを開き、TfsMigrator の場所 (C:\TFSMigrator) に移動します。

  2. ファイルが正しく書式設定され、SAS キーが機能していることを確認するには、次のコマンドを実行してインポート ファイルを検証します。

    TfsMigrator import /importFile:C:\TFSMigrator\import.json /validateonly

    この検証で、SAS キーの有効期間を長くする必要があるというエラーが返されます。

    Screenshot of the command prompt displaying a validation error.

  3. Azure Storage Explorer を使用して期限切れまでの期間を 7 日間に設定した新しい SAS キーを作成します。

    Screenshot of the Storage Explorer **Shared Access Signature** pane displaying the expiration date.

  4. import.json ファイルを更新し、コマンド TfsMigrator import /importFile:C:\TFSMigrator\import.json /validateonly を再実行します。

    今度は、検証が正常に完了します。

    Screenshot of the command prompt displaying a **Validation completed successfully** message.

  5. 次のコマンドを実行してドライ ランを開始します。

    TfsMigrator import /importFile:C:\TFSMigrator\import.json

    移行続行の確認を要求するメッセージが表示されます。 ステージング データが維持される期間がドライ ラン後 7 日間であることに注目してください。

    Screenshot of the message asking Contoso to confirm that they want to continue with the migration.

  6. Microsoft Entra サインイン ウィンドウが表示されたら、Contoso 管理者の資格情報を入力します。

    インポートが正常に開始されたことを確認するメッセージが表示されます。

    Screenshot showing that the import has started successfully.

  7. 15 分後に、次の情報が Web サイトに表示されます。

    Screenshot showing that the collection is being restored.

  8. 移行が完了したら、Contoso の管理者として Azure DevOps Services にサインインし、ドライ ランが正常に動作したことを確認します。 認証後、要求に応じて連絡先情報を入力します。

    プロジェクトが正常に移行されると、ページの上部付近に、ドライラン アカウントが 15 日後に削除されると警告する注意が表示されます。

  9. いずれかのプロジェクトを開き、[作業項目][自分に割り当て済み] を選択します。 作業項目データが ID と共に正常に移行されたことが、このページで確認できます。

    Screenshot of the Azure DevOps Services Work Items page, displaying all the migrated projects.

  10. ソース コードと履歴が移行されたことを確認するために、他のプロジェクトとコードをチェックします。

    Screenshot of the Azure DevOps Services History page, showing that all the code and history have been migrated.

運用環境の移行を実行する

ドライ ランが完了したので、Contoso の管理者は運用環境の移行を開始できます。 ドライ ランを削除し、インポート設定を更新し、インポートをもう一度実行します。

  1. Azure DevOps Services ポータルで、ドライラン用の組織を削除します。

  2. import.json ファイルを更新して、ImportTypeProductionRun に設定します。

    Screenshot of the Azure DevOps Services portal, with the ImportType field set to ProductionRun.

  3. ドライ ランに使用したのと同じコマンドを実行して、移行を開始します。

    TfsMigrator import /importFile:C:\TFSMigrator\import.json

    移行の確認を求めるメッセージが表示されます。 セキュリティで保護されている場所に、最大 7 日間、ステージング領域としてデータを保持できるという警告が表示されます。

    Screenshot of an Azure DevOps Services message warning that the migrated data could be held for up to seven days.

  4. Microsoft Entra サインイン ウィンドウが表示されたら、Contoso 管理者の資格情報を入力します。

    インポートが正常に開始されたというメッセージが表示されます。

    Screenshot of an Azure DevOps Services message that the import has been started successfully.

    15 分後に、次の情報が Web サイトに表示されます。

    Screenshot showing that the data is being copied to the cloud.

  5. 移行が完了したら、Contoso の管理者として Azure DevOps Services にサインインし、プロジェクトが正常に移行されたことを確認します。

  6. プロジェクトを開き、[作業項目]>[自分に割り当て済み] を選択します。 このページに、作業項目データが移行されたことが示されます。

    Screenshot showing that the work item data and identity have been migrated.

  7. 他の作業項目データが移行されていることを確認します。

    Screenshot listing additional work item data to be confirmed.

  8. 他のプロジェクトとコードをチェックして、ソース コードと履歴が移行されていることを確認します。

    Screenshot listing additional project and source code migration to be confirmed.

ソース管理を TFVC から Git に移行する

移行が完了したら、次に Contoso の管理者はソース コード管理を TFVC から Git に移行する必要があります。 そのためには、管理者は、現在 Azure DevOps Services 組織内にあるソース コードを、同じ組織の Git リポジトリとしてインポートします。

  1. Azure DevOps Services ポータルで、TFVC リポジトリ $/PolicyConnect のいずれかを開いて確認します。

    Screenshot of the **$/PolicyConnect** repo in the Azure DevOps Services portal.

  2. ソースの [$/PolicyConnect] ドロップダウン リストから、[リポジトリのインポート] を選択します。

    Screenshot of the **Import repository** link in the Azure DevOps Services portal.

  3. [ソースの種類] ドロップダウン リストから [TFVC] を選択します。 [パス] ボックスにリポジトリのパスを指定し、[インポート] を選択します。 [履歴の移行] チェック ボックスはオフのままにします。

    Screenshot of the **Import from TFVC** pane.

    Note

    TFVC と Git とではバージョン管理情報の保存方法が異なるので、リポジトリの履歴は移行 "しない" ことをお勧めします。

  4. インポートの完了後、コードを確認します。

    Screenshot confirming that the import is successful.

  5. 2 つ目のリポジトリ ($/smarthotelcontainer) について、同じプロセスを繰り返します。

  6. ソースを確認したら、Azure DevOps Services への移行は完了です。 今後は Azure DevOps Services が、この移行にかかわったチームのすべての開発のソースになります。

    Screenshot showing that the migration to Azure DevOps Services is complete.

関連項目:

TFVC から Git にリポジトリをインポートする

移行後にクリーンアップする

移行が完了したので、Contoso チームは次のタスクを実行する必要があります。

  • 追加のインポート アクティビティについては、インポート後に関する記事を参照してください。
  • TFVC リポジトリを削除するか、読み取り専用モードに設定します。 コードベースは使用せず、代わりにそれらを参照して履歴を取得します。

移行後のトレーニング

Contoso チームは関連するチーム メンバーに Azure DevOps Services と Git のトレーニングを用意する必要があります。