テスト実行の移行を実行する

これで、チームは移行のテスト実行を開始し、最後に完全な運用移行を開始するプロセスを開始する準備が整いました。 このフェーズでは、移行プロジェクトの最後に通常実行される他のタスクに加えて、移行をキューに入れる最後の手順について説明します。

前提条件

テスト実行の移行を開始する前にPrepare テスト実行フェーズを完了します。

コレクションを検証する

Azure DevOps Services に移行する各コレクションを検証します。 検証手順では、サイズ、照合順序、ID、プロセスなど、コレクションのさまざまな側面を調べますが、これらに限定されません。

データ移行ツールを使用して検証を実行します。

1. データ移行ツールをダウンロードします。

2. zip ファイルを Azure DevOps Server アプリケーション層のいずれかにコピーします。

3. ファイルを解凍します。 マシンが Azure DevOps Server インスタンスの構成データベースに接続できる限り、Azure DevOps Server がインストールされていない別のコンピューターからツールを実行することもできます。

4. サーバーでコマンド プロンプト ウィンドウを開き、cd コマンドを入力して、データ移行ツールが格納されているディレクトリに移動します。 少し時間を取って、ツールのヘルプ コンテンツを確認してください。

   a. 最上位のヘルプとガイダンスを表示するには、次のコマンドを実行します。

    Migrator /help
   

   b. コマンドのヘルプ テキストを表示します。

    Migrator validate /help 
   

5. コレクションを初めて検証するときは、コマンドに次の単純な構造が必要です。

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

   {name}が Microsoft Entra テナントの名前を提供します。たとえば、DefaultCollection および fabrikam テナントに対して実行する場合、コマンドは次の例のようになります。

    Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}
   

6. Azure DevOps Server以外のコンピューターからツールを実行するには、/connectionString パラメーターが必要です。 接続文字列パラメーターは、Azure DevOps Server構成データベースを指します。 たとえば、検証されたコマンドが Fabrikam 企業によって実行される場合、コマンドは次のようになります。

    Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"
   

   重要

   データ移行ツール コレクション内のデータや構造体 編集することはできません。 コレクションは、問題を特定するためにのみ読み取られます。

7. 検証が完了したら、ログ ファイルと結果を表示できます。

   

   検証中に、一部のパイプラインにパイプラインごとの保持ルールが含まれている場合、警告が表示されます。 Azure DevOps Services では、 project ベースの保持モデルが使用され パイプラインごとの保持ポリシーはサポートされません。 移行を続行した場合、ポリシーはホストされているバージョンに引き継がれられません。 代わりに、既定のプロジェクト レベルのアイテム保持ポリシーが適用されます。 ビルドの損失を回避するために重要なビルドを保持します。

すべての検証に合格したら、移行プロセスの次の手順 に移動できます。 データ移行ツールでエラーにフラグが設定されている場合は、先に進む前に修正してください。 検証エラーの修正に関するガイダンスについては、「 移行と移行のエラーをトラブルシューティングするを参照してください。

ログ ファイルをインポートする

ログ ディレクトリを開くと、いくつかのログ ファイルが表示されることがあります。

メインログ ファイルの名前は DataMigrationTool.log です。 これには、実行されたすべてのものに関する詳細が含まれています。 特定の領域に集中しやすくするために、主要な検証操作ごとにログが生成されます。

たとえば、TfsMigrator が "プロジェクト プロセスの検証" ステップでエラーを報告した場合は、 ProjectProcessMap.log ファイルを開いて、ログ全体をスクロールするのではなく、その手順で実行されたすべてを表示できます。

継承されたモデルを使用するようにプロジェクト プロセスを移行しようとしている場合にのみ、 TryMatchOobProcesses.log ファイルを確認します。 継承されたモデルを使用しない場合は、Azure DevOps Services へのインポートを妨げるので、これらのエラーは無視できます。 詳細については、移行の Validate フェーズを参照してください。

移行ファイルを生成する

データ移行ツールによってコレクションが検証され、"すべてのコレクション検証に合格しました" という結果が返されます。コレクションをオフラインにして移行する前に、移行ファイルを生成します。 prepare コマンドを実行すると、次の 2 つの移行ファイルが生成されます。

• IdentityMapLog.csv: Active Directory と Microsoft Entra ID の間の ID マップの概要を示します。
• migration.json: 移行を開始するために使用する移行仕様を入力する必要があります。

Prepare コマンド

prepare コマンドは、必要な移行ファイルの生成を支援します。 基本的に、このコマンドはコレクションをスキャンして、すべてのユーザーの一覧を検索して ID マップ ログに入力し、 IdentityMapLog.csvし、Microsoft Entra ID に接続して各 ID の一致を見つけようとします。 そのためには、 Microsoft Entra Connect ツール (旧称: ディレクトリ同期ツール、ディレクトリ同期ツール、またはDirSync.exe ツール) を使用する必要があります。

ディレクトリ同期が設定されている場合、データ移行ツールは一致する ID を見つけて、 Active としてマークする必要があります。 一致しない場合、ID は ID マップ ログで Historical としてマークされるため、ユーザーがディレクトリ同期に含まれていない理由を調査する必要があります。移行の前に、移行仕様ファイル ( migration.json) を設定する必要があります。

validate コマンドとは異なり、prepare doesにはインターネット接続が必要です。ID マップ ログ ファイルを設定するには Microsoft Entra ID に接続する必要があるためです。 Azure DevOps Server インスタンスがインターネットにアクセスできない場合は、そのコンピューターからツールを実行します。 Azure DevOps Server インスタンスへのイントラネット接続とインターネット接続を持つマシンが見つかる限り、このコマンドを実行できます。 コマンドの prepare ヘルプを表示するには、次のコマンドを実行します。

Migrator prepare /help

ヘルプ ドキュメントには、Azure DevOps Server インスタンス自体とリモート コンピューターからコマンドをMigrator実行するための手順と例が含まれています。 Azure DevOps Server インスタンスのいずれかのアプリケーション層からコマンドを実行している場合、コマンドの構造は次のようになります。

Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region}

Migrator prepare  /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True"

connectionString パラメーターは、Azure DevOps Server インスタンスの構成データベースへのポインターです。 たとえば、Fabrikam 企業が prepare コマンドを実行する場合、コマンドは次の例のようになります。

Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

データ移行ツールは、 prepare コマンドを実行すると、完全な検証を実行して、前回の完全な検証以降にコレクションで何も変更されないようにします。 新しい問題が検出された場合、移行ファイルは生成されません。

コマンドの実行が開始された直後に、Microsoft Entra サインイン ウィンドウが表示されます。 コマンドで指定されているテナント ドメインに属する ID を使用してサインインします。 指定した Microsoft Entra テナントが、将来の組織でサポートされるテナントであることを確認します。 Fabrikam の例では、ユーザーは次のスクリーンショットの例のような資格情報を入力します。

データ移行ツールで prepare コマンドを正常に実行すると、結果ウィンドウに一連のログと 2 つの移行ファイルが表示されます。 ログ ディレクトリで、ログ フォルダーと 2 つのファイルを見つけます。

• migration.json は移行仕様ファイルです。 時間をかけて記入することをお勧めします。
• IdentityMapLog.csv には、生成された Active Directory から Microsoft Entra ID へのマッピングが含まれています。 移行を開始する前に、完全性を確認してください。

2 つのファイルについては、次のセクションで詳しく説明します。

移行仕様ファイル

移行仕様 migration.jsonは、移行設定を提供する JSON ファイルです。 これには、目的のorganization名、ストレージ アカウント情報、およびその他の情報が含まれます。 ほとんどのフィールドは自動的に設定され、一部のフィールドでは移行を試みる前に入力が必要です。

migration.json ファイルに表示されるフィールドと必要なアクションを次の表に示します。

フィールド	説明	必要なアクション
source	移行に使用されるソース データ ファイルの場所と名前に関する情報。	必要なアクションはありません。 従うサブフィールド アクションの情報を確認します。
場所	データ層アプリケーション パッケージ (DACPAC) をホストする Azure ストレージ アカウントへの共有アクセス署名キー。	必要なアクションはありません。 このフィールドについては、後の手順で説明します。
ファイル	移行データを含むファイルの名前。	必要なアクションはありません。 従うサブフィールド アクションの情報を確認します。
DACPAC	移行中にデータを取り込むためのコレクション データベースをパッケージする DACPAC ファイル。	必要なアクションはありません。 後の手順では、コレクションを使用してこのファイルを作成し、Azure ストレージ アカウントにアップロードします。 このプロセスの後半で生成するときに使用する名前に基づいてファイルを更新します。
ターゲット	移行する新しい組織のプロパティ。	必要なアクションはありません。 従うサブフィールド アクションの情報を確認します。
Name	移行中に作成する組織の名前。	名前を指定します。 名前は、移行が完了した後ですぐに変更できます。 注: 移行を実行する前に、この名前の組織を作成 。 組織は、移行プロセスの一部として作成されます。
ImportType	実行する移行の種類。	必要なアクションはありません。 後の手順で、実行する移行の種類を選択します。
検証データ	移行エクスペリエンスを促進するために必要な情報。	データ移行ツールでは、"ValidationData" セクションが生成されます。 これには、移行エクスペリエンスを促進するのに役立つ情報が含まれています。 このセクションの値を編集しないでください。または、移行の開始に失敗する可能性があります。

上記のプロセスを完了すると、次の例のようなファイルが作成されます。

前の図では、Fabrikam 移行のプランナーが組織名 fabrikam-import を追加し、移行の地理的な場所として CUS (中央米国) を選択しました。 その他の値は、プランナーが移行のためにコレクションをオフラインにする直前に変更されるように残されていました。

移行でサポートされている Azure リージョン

Azure DevOps Services は、いくつかの Azure の地理的な場所で利用できます。 ただし、Azure DevOps Services が利用できるすべての場所が移行でサポートされているわけではありません。 次の表に、移行用に選択できる Azure の地理的な場所を示します。 また、移行のためにその地域をターゲットにするために移行仕様ファイルに配置する必要がある値も含まれます。

地域の場所	Azure の地理的な場所	インポート仕様の値
United States	中央米国	CUS
ヨーロッパ	西ヨーロッパ	WEU
イギリス	イギリス南部	UKS
オーストラリア	オーストラリア東部	EAU
南アメリカ	ブラジル南部	Sbr
アジア太平洋	インド南部	MA
アジア太平洋	東南アジア (シンガポール)	SEA
Canada	カナダ中部	CC

ID マップ ログ

ID マップ ログは、Azure DevOps Services に移行する実際のデータと同等の重要性を持ちます。 ファイルを確認するときは、ID の移行のしくみと、潜在的な結果が何を伴う可能性があるかを理解することが重要です。 ID を移行すると、ID は アクティブ または になります。 アクティブな ID は Azure DevOps Services にサインインできますが、履歴 ID はサインインできません。

アクティブな ID

アクティブ ID は、移行後の Azure DevOps Services のユーザー ID を指します。 Azure DevOps Servicesでは、これらの ID はライセンスが付与され、organizationのユーザーとして表示されます。 ID は、ID マップ ログ ファイルの [予期されるインポート状態] 列でアクティブとしてマークされます。

履歴 ID

履歴 ID は、ID マップ ログ ファイルの [ 予期されるインポート状態] 列にそのようにマップされます。 ファイルに行エントリがない ID も履歴になります。 行エントリのない ID の例として、会社で働かなくなった従業員が考えられます。

アクティブ ID とは異なり、履歴 ID:

• 移行後にorganizationにアクセスすることはできません。
• ライセンスを持っていない。
• organizationにユーザーとして表示されません。 保持されるのは、後で履歴を検索できるように、organizationでその ID の名前の概念です。 会社で働かなくなったユーザー、または組織への追加アクセスを必要としないユーザーには、履歴 ID を使用することをお勧めします。

ID マップ ログ ファイルを理解する

ID マップ ログ ファイルは、次に示す例のようになります。

ID マップ ログ ファイルの列を次の表に示します。

お客様と Microsoft Entra 管理者は、 一致が見つからない (Microsoft Entra ID 同期の確認) としてマークされたユーザーを調査して、Microsoft Entra Connect Sync に含まれていない理由を理解する必要があります。

列	説明
Active Directory: ユーザー (Azure DevOps Server)	Azure DevOps Serverの ID によって使用されるフレンドリ表示名。 この名前を使用すると、マップ内の行が参照しているユーザーを簡単に識別できます。
Active Directory: セキュリティ識別子	Azure DevOps Serverのオンプレミスの Active Directory ID の一意識別子。 この列は、コレクション内のユーザーを識別するために使用されます。
Microsoft Entra ID: 予期されるインポート ユーザー (Azure DevOps Services)	一致する間もなくアクティブになるユーザーの予想されるサインイン アドレスまたは 一致が見つかりません (Microsoft Entra ID 同期の確認)。これは、Microsoft Entra ID Sync 中に ID が失われ、履歴としてインポートされたことを示します。
予期されるインポートの状態	想定されるユーザー移行の状態: Active Active Directory と Microsoft Entra ID の間に一致するものがある場合、または一致しない場合は Historical 。
検証日	ID マップ ログが最後に検証された時刻。

ファイルを読み進める際に、[ 予期されるインポート状態] 列の値が [アクティブ ] または [履歴] のどちらであるかに注意してください。 アクティブ は、移行時にこの行の ID が正しくマップされることを示します。 履歴 は、ID が移行時に履歴になることを意味します。 生成されたマッピング ファイルの完全性と正確性を確認することが重要です。

1. 正しく一致する ID を確認します。 すべての予想される ID が存在しますか? ユーザーは正しい Microsoft Entra ID にマップされていますか?

   値を変更する必要がある場合は、Microsoft Entra 管理者に連絡して、オンプレミスの Active Directory ID が Microsoft Entra ID との同期の一部であることを確認し、正しく設定してください。 詳細については、「 Microsoft Entra ID を使用してオンプレミス ID を統合するを参照してください。

2. 次に、 履歴としてラベル付けされている ID を確認します。 このラベル付けは、次のいずれかの理由により、一致する Microsoft Entra ID が見つからなかったことを意味します。

   • ID は、オンプレミスの Active Directoryと Microsoft Entra ID の間の同期用に設定されていません。
   • Id はまだ Microsoft Entra ID に設定されていません (たとえば、新しい従業員がいます)。
   • ID は Microsoft Entra インスタンスに存在しません。
   • その ID を所有するユーザーは、会社で動作しなくなりました。

最初の 3 つの理由に対処するには、Microsoft Entra ID と同期する目的のオンプレミスの Active Directory ID を設定します。 詳細については、「 Microsoft Entra ID を使用してオンプレミス ID を統合するを参照してください。 Azure DevOps Services で id を active としてインポートするように Microsoft Entra Connect を設定して実行する必要があります。

会社にいなくなった従業員は 履歴としてインポートする必要があるため、4 番目の理由は無視できます。

履歴 ID (小規模チーム)

Microsoft Entra Connect が構成されていない場合、ID マップ ログ ファイル内のすべてのユーザーは historical としてマークされます。 この方法で移行を実行すると、すべてのユーザーが historical としてインポートされます。 Microsoft Entra Connect を構成して、ユーザーがアクティブとしてインポートされるようにすることを強くお勧めします。

すべての履歴 ID を使用して移行を実行すると、慎重に検討する必要があります。 Microsoft Entra Connect を設定するコストが高すぎると見なされるユーザーが少ないチームのみが考慮する必要があります。

すべての ID を履歴として移行するには、後のセクションで説明する手順に従います。 移行をキューに入れると、移行のキューに使用される ID が組織の所有者として組織にブートストラップされます。 他のすべてのユーザーは履歴としてインポートされます。 その後、組織の所有者は、Microsoft Entra ID を使用してユーザーを再度追加できます。 追加されたユーザーは、新しいユーザーとして扱われます。 彼らは自分の歴史を*所有していませんし、この履歴を Microsoft Entra ID に親しむ方法はありません。 ただし、ユーザーは自分の \<domain>\<Active Directory username>を検索することで、移行前の履歴を引き続き検索できます。

完全な履歴 ID シナリオが検出されると、データ移行ツールに警告が表示されます。 この移行パスを下に移動する場合は、ツールで制限事項に同意する必要があります。

Visual Studio サブスクリプション

データ移行ツールは、ID マップ ログ ファイルを生成するときに、Visual Studio サブスクリプション (旧称 MSDN 特典) を検出できません。 代わりに、移行後に自動ライセンス アップグレード機能を適用することをお勧めします。 ユーザーの職場アカウントが リンクされている限り 移行後の最初のサインイン時に、Azure DevOps Services によって Visual Studio サブスクリプションの特典が自動的に適用されます。 移行中に割り当てられたライセンスに対して課金されることはありません。そのため、後でサブスクリプションを安全に処理できます。

ユーザーの Visual Studio サブスクリプションが Azure DevOps Services で自動的にアップグレードされない場合は、テスト実行の移行を繰り返す必要はありません。 Visual Studio サブスクリプションのリンクは、移行の範囲外で行われます。 移行前または移行後に職場アカウントが正しくリンクされている限り、ユーザーのライセンスは次回のサインイン時に自動的にアップグレードされます。 ライセンスが正常にアップグレードされると、次回移行を実行すると、ユーザーは組織への最初のサインイン時に自動的にアップグレードされます。

移行を準備する

これで、テスト実行の移行で実行できる準備がすべて整いました。 移行のためにコレクションをオフラインにするように、チームでダウンタイムをスケジュールします。 移行を実行する時間に同意したら、生成した必要な資産とデータベースのコピーを Azure にアップロードします。 移行の準備は、次の 5 つの手順で構成されます。

手順 1: コレクションをオフラインにしてデタッチします。 手順 2: 移行するコレクションから DACPAC ファイルを生成します。
手順 3: DACPAC ファイルと移行ファイルを Azure ストレージ アカウントにアップロードします。
手順 4: ストレージ アカウントにアクセスするための SAS トークンを生成します。
手順 5: 移行仕様を完了します。

手順 1: コレクションをデタッチする

コレクションをデタッチすることは 移行プロセスの重要な手順です。 コレクションの ID データは、コレクションがアタッチされている間、Azure DevOps Server インスタンスの構成データベースに存在します。 コレクションがAzure DevOps Server インスタンスからデタッチされると、その ID データのコピーを受け取り、コレクションと共にトランスポート用にパッケージ化します。 このデータがないと、移行の ID 部分 実行 できません。

テストの実行でダウンタイムをゼロにすることを選択するコストを比較検討することが重要です。 コレクションと構成データベースのバックアップを作成し、SQL インスタンスに復元してから、デタッチされたバックアップを作成する必要があります。 コスト分析では、デタッチされたバックアップを直接取得するために、わずか数時間のダウンタイムを要する方が最終的に優れていることが証明される可能性があります。

手順 2: DACPAC ファイルを生成する

DACPAC は、コレクションをAzure DevOps Servicesに移動するための高速かつ比較的簡単な方法を提供します。 ただし、コレクション データベースのサイズが特定のしきい値を超えると、DACPAC を使用する利点が減少し始めます。

DACPAC は、データベースを 1 つのファイルにパッケージ化し、SQL Server の他のインスタンスにデプロイできるようにする SQL Server の機能です。 DACPAC ファイルはAzure DevOps Servicesに直接復元することもできます。そのため、クラウドでコレクションのデータを取得するためのパッケージ化方法として使用できます。

SqlPackage リリース ノートから最新の MSI インストーラーを使用してSqlPackage.exeをダウンロードしてインストール。

MSI インストーラーを使用すると、SqlPackage.exe %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\のようなパスにインストールされます。

DACPAC を生成するときは、DACPAC が保存されているディスクと、DACPAC を生成するコンピューター上のディスク領域という 2 つの考慮事項に注意してください。 操作を完了するのに十分なディスク領域があることを確認する必要があります。

パッケージが作成されると、SqlPackage.exeは、パッケージ化要求を開始するコンピューターのドライブ C の一時ディレクトリにコレクションのデータを一時的に格納します。

ドライブ C が小さすぎて DACPAC の作成がサポートされていない場合があります。 コレクション データベースで最大のテーブルを検索することで、必要な領域の量を見積もることができます。 DACPAC は、一度に 1 つのテーブルで作成されます。 生成を実行するための最大領域要件は、コレクションのデータベース内の最大テーブルのサイズとほぼ同じです。 生成された DACPAC をドライブ C に保存する場合は、検証の実行から DataMigrationTool.log ファイルで報告されるコレクション データベースのサイズを検討してください。

DataMigrationTool.log ファイルには、コマンドを実行するたびに、コレクション内の最大のテーブルの一覧が表示されます。 コレクションのテーブル サイズの例については、次の出力を参照してください。 最大テーブルのサイズと、一時ディレクトリをホストするドライブ上の空き領域を比較します。

[Info   @08:23:59.539] Table name                               Size in MB
[Info   @08:23:59.539] dbo.tbl_Content                          38984
[Info   @08:23:59.539] dbo.tbl_LocalVersion                     1935
[Info   @08:23:59.539] dbo.tbl_Version                          238
[Info   @08:23:59.539] dbo.tbl_FileReference                    85
[Info   @08:23:59.539] dbo.Rules                                68
[Info   @08:23:59.539] dbo.tbl_FileMetadata                     61

一時ディレクトリをホストするドライブに、少なくとも同じ空き領域があることを確認します。 そうでない場合は、環境変数を設定して一時ディレクトリをリダイレクトする必要があります。

SET TEMP={location on disk}

もう 1 つの考慮事項は、DACPAC データを保存する場所です。 保存した場所を遠くのリモート ドライブにポイントすると、生成時間が長くなる可能性があります。 ソリッドステート ドライブ (SSD) などの高速ドライブをローカルで使用できる場合は、DACPAC の保存場所としてドライブをターゲットにすることをお勧めします。 それ以外の場合は、リモート ドライブではなく、コレクション データベースが存在するコンピューター上にあるディスクを常に高速に使用できます。

DACPAC のターゲットの場所を特定し、十分な領域があることを確認したら、DACPAC ファイルを生成します。

コマンド プロンプト ウィンドウを開き、SqlPackage.exeの場所に移動します。 DACPAC を生成するには、プレースホルダーの値を必要な値に置き換え、次のコマンドを実行します。

SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

• データ ソース: Azure DevOps Server コレクション データベースをホストするSQL Server インスタンス。
• 初期カタログ: コレクション データベースの名前。
• targetFile: ディスク上の場所と DACPAC ファイル名。

Azure DevOps Server データ層自体で実行されている DACPAC 生成コマンドを次の例に示します。

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

コマンドの出力は DACPAC ファイルで、コレクション データベース Foo から生成され、 Foo.dacpac と呼ばれます。

移行用にコレクションを構成する

コレクション データベースが Azure VM に復元されたら、Azure DevOps Services がデータベースに接続してデータを移行できるように SQL サインインを構成します。 このサインインでは、単一データベースへの 読み取り アクセスのみが許可されます。

開始するには、VM でSQL Server Management Studioを開き、インポートするデータベースに対して新しいクエリ ウィンドウを開きます。

データベースの回復を単純に設定します。

ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;

データベースの SQL サインインを作成し、そのサインインを 'TFSEXECROLE' に割り当てます。

USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

Fabrikam の例に従って、2 つの SQL コマンドは次の例のようになります。

ALTER DATABASE [Fabrikam] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

VM をターゲットにするように移行仕様ファイルを構成する

SQL Server インスタンスに接続する方法に関する情報を含むように、移行仕様ファイルを更新します。 移行仕様ファイルを開き、次の更新を行います。

1. ソース ファイル オブジェクトから DACPAC パラメーターを削除します。

   変更前の移行の仕様を次のコードに示します。

   

   変更後の移行の仕様を次のコードに示します。

   

2. 必要なパラメーターを入力し、ソース オブジェクト内の次の properties オブジェクトを仕様ファイルに追加します。

   "Properties":
   {
       "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" 
   }
   

変更を適用すると、移行の仕様は次の例のようになります。

これで、移行に SQL Azure VM を使用するように移行仕様が構成されました。 残りの準備手順に進み、Azure DevOps Services に移行します。 移行が完了したら、必ず SQL サインインを削除するか、パスワードをローテーションしてください。 移行が完了した後も、サインイン情報は保持されません。

手順 3: DACPAC ファイルをアップロードする

DACPAC は Azure ストレージ コンテナーに配置する必要があります。これは、既存のコンテナーでも、移行作業専用に作成されたものでもかまいません。 コンテナーが適切な地理的な場所に作成されるようにすることが重要です。

Azure DevOps Services は、複数の 地理上の場所で利用できます。 これらの場所にインポートするときは、移行が正常に開始されるようにデータを正しく配置することが重要です。 データは、インポート先と同じ地理的な場所に配置する必要があります。 データを他の場所に配置すると、移行を開始できなくなります。 次の表に、ストレージ アカウントの作成とデータのアップロードに使用できる地理的な場所を示します。

必要な移行の地理的な場所	ストレージ アカウントの地理的な場所
中央米国	中央米国
西ヨーロッパ	西ヨーロッパ
イギリス	イギリス南部
オーストラリア東部	オーストラリア東部
ブラジル南部	ブラジル南部
インド南部	インド南部
カナダ中部	カナダ中部
アジア太平洋 (シンガポール)	アジア太平洋 (シンガポール)

Azure DevOps Services は米国内の複数の地理的な場所で利用できますが、新しい Azure DevOps Services を受け入れるのは中央米国の場所のみです。 現時点では、他の米国の Azure の場所にデータを移行することはできません。

Azure portal から BLOB コンテナーを作成します。 コンテナーを作成したら、コレクション DACPAC ファイルをアップロードします。

移行が完了したら、 AzCopy、 Azure Storage Explorer などの他の Azure Storage Explorer ツール ( Azure Storage Explorer など) を使用して、BLOB コンテナーと付随するストレージ アカウントを削除。

手順 4: SAS トークンを生成する

Shared Access Signature (SAS) トークンは、ストレージ アカウント内のリソースへの委任されたアクセスを提供します。 このトークンを使用すると、移行を実行するためにデータにアクセスするために必要な最小レベルの特権を Microsoft に付与できます。

Azure portal を使用 SAS トークンを生成。 セキュリティの観点から、次のタスクを実行することをお勧めします。

1. SAS トークンのアクセス許可として Read と List のみを選択します。 その他のアクセス許可は必要ありません。
2. 有効期限を 7 日以内に設定します。
3. Azure DevOps Services IP のみにアクセスを制限する。
4. SAS キーをシークレットとして扱います。 コンテナーに格納されているデータへの読み取りと一覧のアクセスを許可するため、キーを安全でない場所に残さないでください。

手順 5: 移行仕様を完了する

プロセスの前半で、移行仕様ファイル ( migration.json と呼ばれます) を部分的に入力しました。 この時点で、移行の種類を除く残りのすべてのフィールドを完了するのに十分な情報が得られます。 移行の種類については、後の「移行」セクションで説明します。

migration.json仕様ファイルの Source で、次のフィールドに入力します。

• 場所: スクリプトから生成した SAS キーを貼り付け、前の手順でコピーしました。
• Dacpac: .dacpac ファイル拡張子を含むファイルの名前が、ストレージ アカウントにアップロードした DACPAC ファイルと同じであることを確認します。

最終的な移行仕様ファイルは、次の例のようになります。

移行の種類を決定する

インポートは、テスト実行または運用実行としてキューに登録できます。 ImportType パラメーターによって、移行の種類が決まります。

• TestRun: テストの目的でテストの実行を使用します。 システムは、45 日後にテストの実行を削除します。
• ProductionRun: 結果として得られる移行を維持し、移行が完了した後に Azure DevOps Services で組織をフルタイムで使用する場合は、運用実行を使用します。

テスト実行組織

テスト実行組織は、チームがコレクションの移行をテストするのに役立ちます。 運用移行を実行する前に、完了した テスト実行組織を削除する必要があります。 すべてのテスト実行組織には、 制限された存在があり、一定の期間が経過すると自動的に削除されます。 組織が削除されるタイミングに関する情報は、移行の完了後に受信する必要がある成功メールに含まれます。 この日付をメモし、それに応じて計画してください。

テスト実行組織は、削除される 45 日前までです。 指定した期間が経過すると、テスト実行組織が削除されます。 実稼働移行を行う前に、テスト実行インポートを必要な回数繰り返すことができます。

テストの実行を削除します

新しいテストを試みる前に、以前のテスト実行をすべて削除します。 チームが運用環境への移行を実行する準備ができたら、テスト実行組織を手動で削除する必要があります。 2 回目のテスト実行移行または最終的な運用移行を実行する前に、前のテスト実行で作成した以前の Azure DevOps Services 組織をすべて削除してください。 詳細については、「 組織の削除」を参照してください。

削除または名前の変更後にorganization名が使用可能になるまでに最大 1 時間かかる場合があります。 詳細については、 Post 移行タスク 記事を参照してください。

移行の問題が発生した場合は、「 移行と移行のエラーを解決するを参照してください。

移行を実行する

これで、チームは移行を実行するプロセスを開始する準備ができました。 運用環境での移行を試みる前に、テスト実行の移行を成功させておくことをお勧めします。 テスト実行インポートでは、運用環境の実行に進む前に、移行の外観を事前に確認し、潜在的な問題を特定し、エクスペリエンスを得ることができます。

• Azure 管理者は、ユーザーが新しい Azure DevOps 組織を作成できないようにすることができます。 Microsoft Entra テナント ポリシーが有効になっている場合、移行は完了しません。 開始する前に、ポリシーが設定されていないこと、または移行を実行しているユーザーに例外があることを確認します。 詳細については、「 Microsoft Entra テナント ポリシーを使用した組織の作成を参照してください。
• Azure DevOps Services では、パイプラインごとの保持ポリシーはサポートされておらず、ホストされているバージョンに引き継がれることはありません。

ロールバック 計画に関する考慮事項

最終的な運用実行を行うチームの一般的な懸念事項は、移行に問題がある場合のロールバック計画です。 Azure DevOps 用データ移行ツールに提供する移行設定をテストできるように、テスト実行を行うことを強くお勧めします。

最終的な運用実行のロールバックは非常に簡単です。 移行をキューに入れる前に、チーム プロジェクト コレクションを Azure DevOps Server からデタッチします。これにより、チーム メンバーが使用できなくなります。 何らかの理由で運用実行をロールバックし、オンプレミス サーバーをチーム メンバーのためにオンラインに戻す必要がある場合は、これを行うことができます。 チーム プロジェクト コレクションをもう一度オンプレミスにアタッチし、チームが再グループ化して潜在的な障害を把握している間も正常に動作することをチームに通知します。

その後、原因を特定できない場合は、Azure DevOps Services カスタマー サポートにお問い合わせください。 詳細については、 トラブルシューティングの記事を参照してください。 カスタマー サポート チケットは、次のページ https://aka.ms/AzureDevOpsImportSupportから開くことができます。 問題で製品グループのエンジニアがこれらのケースに取り組む必要がある場合は、通常の営業時間中に処理されることに注意してください。

Azure DevOps Server からチーム プロジェクト コレクションをデタッチして、移行の準備をします。

SQL データベースのバックアップを生成する前に、データ移行ツールでは、コレクションを Azure DevOps Server (SQL ではなく) から完全にデタッチする必要があります。 Azure DevOps Server のデタッチ プロセスは、コレクション データベースの外部に格納されているユーザー ID 情報を転送し、新しいサーバーまたはこの場合は Azure DevOps Services に移動できるようにします。

コレクションのデタッチは、Azure DevOps Server インスタンス上の Azure DevOps Server 管理コンソールから簡単に行うことができます。 詳細については、「 Move プロジェクト コレクション、コレクションのデタッチ」を参照してください。

移行をキューに入れます

Data Migration Tool の import コマンドを使用して移行を開始します。 移行コマンドは、移行仕様ファイルを入力として受け取ります。 ファイルを解析して、指定された値が有効であることを確認し、成功した場合は Azure DevOps Services への移行をキューに入れます。 移行コマンドにはインターネット接続が必要ですが、Azure DevOps Server インスタンスへの接続は必要ありません*。

開始するには、コマンド プロンプト ウィンドウを開き、データ移行ツールのパスにディレクトリを変更します。 ツールで提供されるヘルプ テキストを確認することをお勧めします。 次のコマンドを実行して、移行コマンドのガイダンスとヘルプを確認します。

Migrator import /help

移行をキューに登録するコマンドの構造は次のとおりです。

Migrator import /importFile:{location of migration specification file}

次の例は、完了した移行コマンドを示しています。

Migrator import /importFile:C:\DataMigrationToolFiles\migration.json

検証に合格したら、ID マップ ログ ファイルが作成されたのと同じ Microsoft Entra テナントのメンバーである ID を使用して Microsoft Entra ID にサインインします。 サインインしているユーザーは、インポートされた組織の所有者です。

チームが移行を開始すると、移行をキューに入れたユーザーに電子メール通知が送信されます。 移行のキューに入ってから約 5 分から 10 分後に、チームは組織に移動して状態を確認できます。 移行が完了すると、チームはサインインするように指示され、電子メール通知が組織の所有者に送信されます。

データ移行ツールは、移行前に修正する必要があるエラーにフラグを設定します。 この記事では、移行の準備中に発生する可能性がある最も一般的な警告とエラーについて説明します。 各エラーを修正した後、 migrator validate コマンドをもう一度実行して解決を確認します。

次のステップ

関連記事

• 移行の概要
• 移行後のタスク