テスト実行移行の準備

[アーティクル]
05/21/2024

この記事では、データ移行ツールで必要なチームの準備とファイルの生成について説明します。

強調表示されている移行の 7 段階のテスト実行ステージの準備の図。

前提条件

テスト実行移行の準備を開始する前に、検証フェーズを完了します。

移行設定を生成する

次の手順を実行して、移行仕様と関連ファイルを生成して、コレクションデータベースの移行をキューに入れます。

次のパラメーターを使用して、データ移行ツールの準備コマンドを実行します。

/collection:http://localhost:8080/tfs/DefaultCollection/ tenantDomainName:contoso.com /Region:CUS
- テナントの doメイン name オプションは、会社の Microsoft Entra ID テナントの名前です。
- prepare コマンドにはインターネットアクセスが必要です。 Azure DevOps Server にインターネット接続がない場合は、別のコンピューターからコマンドを実行します。
- "組織リージョン" という用語は、コレクションを Azure DevOps Services に移行する予定の場所を指します。以前にリージョンを選択し、その短縮コードを記録しました。 prepare コマンドでこのコードを使用します。
Microsoft Entra ID テナント内のすべてのユーザーに関する情報を読み取るアクセス許可を持つテナントのユーザーを使用してサインインします。

移行仕様ファイルを構成する

移行仕様ファイルは、次のアクションを実行する方法をデータ移行ツールに指示する JSON ファイルです。

移行した組織を構成する
ソースの場所を指定する
移行をカスタマイズする

多くのフィールドは準備手順中に自動的に設定されますが、次のフィールドを構成する必要があります。

組織名: データを移行するために作成する組織の名前。
場所: Azure ストレージコンテナーにアップロードするデータベースと移行ファイルのバックアップ。このフィールドは、Azure ストレージコンテナーに安全に接続してソースファイルを読み取るために移行ツールで使用される SAS キーを指定します。ストレージコンテナーの作成については、フェーズ 5 の後半で説明し、SAS キーの生成については、新しい移行のキューに入る前にフェーズ 6 で説明します。
DACPAC: コレクションの SQL データベースをパッケージするファイル。
移行の種類: 移行の種類: テスト実行または運用実行。

各移行仕様ファイルは、1 つのコレクション用です。別のコレクションに対して生成された移行仕様ファイルを使用しようとすると、移行は開始されません。移行する各コレクションのテスト実行を準備し、生成された移行仕様ファイルを使用して移行をキューに登録する必要があります。

ID マップログファイルを確認する

ID マップログは、移行する実際のデータと同じくらい重要です。ログファイルを調べるときに、ID 移行の機能と潜在的な結果を理解します。 ID を移行する場合は、アクティブまたは履歴のいずれかを指定できます。アクティブな ID は Azure DevOps Services にサインインできますが、履歴 ID はサインインできません。使用される型は、サービスによって決定されます。

Note

ID が履歴 ID として移行されると、それをアクティブな 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 を使用することをお勧めします。

Note

ID が履歴として移行された後は、アクティブにすることはできません。

ライセンス

移行中は、ID マッピングログの [インポート状態の予測] 列に "アクティブ" と表示されているすべてのユーザーに対してライセンスが自動的に割り当てられます。ライセンスの自動割り当てが正しくない場合は、移行完了後に 1 人以上のユーザーの "アクセスレベル" を編集して変更できます。

割り当てが必ずしも完璧であるとは限らないため、次の月の最初の月まで、必要に応じてライセンスを再割り当てする必要があります。翌月の 1 日までにサブスクリプションを組織にリンクせず、正しい数のライセンスを購入した場合、すべての猶予期間ライセンスが取り消されます。または、自動割り当てで来月購入したライセンスよりも多くのライセンスが割り当てられた場合、追加のライセンスに対して課金されることはありませんが、未払いのライセンスはすべて取り消されます。

アクセスが失われないように、月の最初の前にサブスクリプションをリンクし、必要なライセンスを購入することをお勧めします。課金は毎月実行されます。すべてのテスト実行について、組織がアクティブである限り、ライセンスは無料です。

Azure DevOps サブスクリプション

Visual Studio サブスクリプションは、移行に既定では割り当てられません。代わりに、Visual Studio サブスクリプションを持つユーザーは、そのライセンスを使用するように自動的にアップグレードされます。ユーザーの職場組織が正しくリンクされている場合、Azure DevOps Services は、移行後の最初のサインイン時に Visual Studio サブスクリプションの特典を自動的に適用します。

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

Azure Storage アカウントへのアクセスを、Azure DevOps Services の IP のみに制限します。アクセスを制限するには、コレクションデータベースの移行プロセスに関係する Azure DevOps Services IP からの接続のみを許可します。ストレージアカウントへのアクセスを許可する必要がある IP は、移行先のリージョンによって異なります。

オプション 1: サービスタグを使用する

ポータルまたはプログラムを使用して、ネットワークセキュリティグループまたはファイアウォールにサービスタグを追加 azuredevops することで、すべての Azure DevOps Services リージョンからの接続を簡単に許可できます。

オプション 2: IP リストを使用する

このコマンドを IpList 使用して、特定の Azure DevOps Services リージョンからの接続を許可するためにアクセス権を付与する必要がある IP の一覧を取得します。

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

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

IP の一覧は、ポータルまたはプログラムを使用して、ネットワークセキュリティグループまたはファイアウォールに追加できます。

SQL Azure の IP ファイアウォール例外を構成する

このセクションは、SQL Azure のファイアウォール例外の構成にのみ適用されます。 DACPAC の移行については、「Azure Storage ファイアウォールと仮想ネットワークの構成」を参照してください。

データ移行ツールでは、Azure DevOps Services IP がポート 1433でのみ受信接続用に構成されている必要があります。

SQL Azure VM の Azure ネットワーク層で処理される必要な IP に例外を付与するには、次の手順を実行します。

Azure portal にサインインします。
SQL Azure VM に移動します。
[設定] の [ネットワーク] を選択します。
[受信ポートの規則を追加する] を選択します。
特定の IP の受信ポート規則を構成するには、[詳細設定] を選択します。
[送信元] ドロップダウンリストで、[IP アドレス] を選択し、例外を許可する必要がある IP アドレスを入力し、[宛先ポートの範囲] を 1433 [名前] ボックスに、構成する例外を最もよく表す名前を入力します。

他の構成済みの受信ポート規則によっては、Azure DevOps Services 例外の既定の優先順位を変更する必要があるため、無視されないようにする必要があります。たとえば、Azure DevOps Services の例外よりも優先度が高い "1433 へのすべての受信接続で拒否" ルールがある場合、データ移行ツールはデータベースに正常に接続できない可能性があります。

受信ポート規則の構成が完了したスクリーンショット。

必要なすべての Azure DevOps Services IP に例外が付与されるまで、受信ポート規則の追加を繰り返します。 IP が 1 つ見つからないと、移行の開始に失敗する可能性があります。

大規模なコレクションを移行する

データ移行ツールが警告するデータベースが大きすぎる場合、Azure DevOps Services に移行するには、別のデータパッケージ化アプローチが必要です。コレクションがサイズのしきい値を超えているかどうかわからない場合は、コレクションに対してデータ移行ツールの検証を実行する必要があります。検証により、移行に SQL Azure VM メソッドを使用する必要があるかどうかを確認できます。

コレクションサイズを小さくできるかどうかを判断する

古いデータをクリーンできるかどうかを確認します。時間の経過と同時に、コレクションは大量のデータを構築できます。この増加は DevOps プロセスの自然な部分ですが、すべてのデータを保持する必要がない場合があります。関連しなくなったデータの一般的な例としては、古いワークスペースとビルド結果があります。

データ移行ツールはコレクションをスキャンし、以前にメンションした制限と比較します。次に、コレクションが DACPAC または SQL 移行方法の対象であるかどうかを報告します。一般に、コレクションが DACPAC の制限内に収まるほど小さい場合は、より高速でシンプルな DACPAC アプローチを使用できます。ただし、コレクションが大きすぎる場合は、SQL 移行方法を使用する必要があります。これには、SQL Azure VM の設定とデータベースの手動移行が含まれます。

サイズの制限

現在の制限は次のとおりです。

DACPAC の 150 GB の合計データベースサイズ (データベースメタデータ + BLOB) がこの制限を超えた場合は、SQL 移行方法を実行する必要があります。
DACPAC の 30 GB の個々のテーブルサイズ (データベースメタデータ + BLOB) が、1 つのテーブルがこの制限を超える場合は、SQL 移行方法を実行する必要があります。
SQL 移行方法の 1,536 GB のデータベースメタデータサイズ。この制限を超えると警告が発生します。移行を成功させるには、このサイズを維持することをお勧めします。
SQL 移行方法の 2,048 GB のデータベースメタデータサイズ。この制限を超えるとエラーが発生するため、移行を実行できません。
SQL 移行方法の BLOB サイズに制限はありません。

古くて関連性のなくなった成果物をクリーンすると、予想以上に多くの領域が削除される可能性があり、DACPAC 移行方法と SQL Azure VM のどちらを使用するかが決まります。

重要

古いデータを削除した後は、コレクションの古いバックアップを復元しない限り、復元できません。

DACPAC しきい値を超えている場合は、手順に従って移行用の DACPAC を生成します。それでも DACPAC しきい値の下にデータベースを取得できない場合は、Azure DevOps Services に移行するように SQL Azure VM を設定する必要があります。

Azure DevOps Services に移行するように SQL Azure VM を設定する

Azure DevOps Services に移行するように SQL Azure 仮想マシン (VM) を設定するには、次の大まかな手順を実行します。

SQL Azure VM を設定する
IP ファイアウォールの例外を構成する
VM でデータベースを復元する
[移行用にコレクションを構成する
VM をターゲットにするように移行仕様ファイルを構成する

SQL Azure VM を設定する

Azure portal から SQL Azure VM をすばやく設定できます。詳細については、「Azure portal を使用して SQL Server を使用して Windows 仮想マシンをプロビジョニングする」を参照してください。

SQL Azure VM と接続されたデータディスクのパフォーマンスは、移行のパフォーマンスに大きな影響を与えます。このため、次のタスクを実行することを強くお勧めします。

レベル以上の VM サイズを D8s_v5_* 選択します。
マネージドディスクの使用。
仮想マシンとディスクのパフォーマンスを確認します。 VM IOPS (1 秒あたりの入力/出力) とストレージ IOPS が移行のパフォーマンスのボトルネックにならないように、インフラストラクチャが構成されていることを確認します。たとえば、VM から IOPS をサポートするには、VM に接続されているデータディスクの数で十分であることを確認します。

Azure DevOps Services は、世界中のいくつかの Azure リージョンで利用できます。移行が正常に開始されるようにするには、データを適切なリージョンに配置することが重要です。 SQL Azure VM を間違った場所に設定した場合、移行の開始に失敗します。

重要

Azure VM にはパブリック IP アドレスが必要です。

この移行方法を使用している場合は、サポートされているリージョンに VM を作成します。 Azure DevOps Services は米国 (米国) の複数のリージョンで利用できますが、新しい組織を受け入れるのは中央米国リージョンのみです。現在、他の米国の Azure リージョンにデータを移行することはできません。

Note

DACPAC のお客様は、「手順 3: DACPAC ファイルをアップロードする](migration-test-run.md#)」セクションのリージョンテーブルを参照してください。上記のガイドラインは、SQL Azure VM のみを対象としています。 DACPAC のお客様の場合は、移行でサポートされている Azure リージョンを参照してください。

次の SQL Azure VM 構成を使用します。

ドライブ C 以外のドライブを使用するように SQL 一時データベースを構成します。理想的には、ドライブには十分な空き領域が必要です。は、データベースの最大テーブルと少なくとも同等です。
サイズを小さくした後もソースデータベースが 1 テラバイト (TB (テラバイト)) を超える場合は、1 TB (テラバイト) ディスクをさらに接続し、それらを 1 つのパーティションに結合して VM にデータベースを復元する必要があります。
コレクションデータベースのサイズが 1 TB (テラバイト)を超える場合は、一時データベースとコレクションデータベースの両方に SSD (ソリッドステートハードドライブ) を使用することを検討してください。また、16 個の仮想 CPU (vCPU) と 128 GB (ギガバイト) の RAM (ランダムアクセスメモリ) を備えた大規模な VM の使用も検討してください。

VM でデータベースを復元する

Azure VM を設定して構成したら、デタッチされたバックアップを Azure DevOps Server インスタンスから Azure VM に取り込む必要があります。コレクションデータベースは SQL インスタンスに復元する必要があり、VM にAzure DevOps Serverをインストールする必要はありません。

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

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

VM で SQL Server Management Studio を開き、移行するデータベースに対して新しいクエリウィンドウを開きます。
データベースの回復を単純に設定します。
```
ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;
```

次の例のように、データベースの SQL サインインを作成し、そのサインインを 'TF Standard Edition XECROLE' に割り当てます。

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>'

SQL コマンドの次の例を参照してください。

    ALTER DATABASE [Foo] SET RECOVERY SIMPLE; 
     
    USE [Foo] 
    CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!' 
    CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo] 
    EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

重要

VM 上の SQL Server Management Studio で SQL Server とWindows 認証モードを有効にします。認証モードを有効にしない場合、移行は失敗します。

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

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

ソースファイルオブジェクトから DACPAC パラメーターを削除します。変更前の移行仕様は、次のコード例のようになります。

変更後の移行仕様は、次のコード例のようになります。

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

"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 を参照する移行仕様のスクリーンショット。

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

選択したデータセンターに Azure Storage コンテナーを作成する

Azure DevOps 用データ移行ツールを使用するには、最終的な Azure DevOps Services 組織と同じ Azure データセンターに Azure Storage コンテナーが必要です。たとえば、中央の米国データセンターに Azure DevOps Services 組織を作成する場合は、その同じデータセンターに Azure Storage コンテナーを作成します。このアクションにより、同じデータセンター内で転送が行われるため、SQL データベースの移行にかかる時間が大幅に短縮されます。

詳しくは、「ストレージアカウントの作成」をご覧ください。

請求の設定

新しく移行された Azure DevOps Services 組織に猶予期間が設けられているため、チームは必要な手順を完了し、ライセンスの割り当てを修正できます。ユーザープラン、ビルドまたはデプロイパイプライン、ホストされたビルドサービス、ホストされたロードテストサービスなどを購入することが予想される場合は、移行した組織にリンクする準備ができている Azure サブスクリプションがあることを確認することを強くお勧めします。猶予期間は、移行が完了した翌月の最初の日に終了します。

リンクを行う必要がある場合は、移行後フェーズ (リンク) でもう一度お知らせします。この準備手順では、後の手順で使用する Azure サブスクリプションを確実に把握します。詳細については、「組織の課金を設定する」を参照してください。

次のステップ

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

次の方法で共有

テスト実行移行の準備

前提条件

移行設定を生成する

移行仕様ファイルを構成する

ID マップログファイルを確認する

アクティブな ID

履歴 ID

ライセンス

Azure DevOps サブスクリプション

Azure DevOps Services IP のみにアクセスを制限する

オプション 1: サービスタグを使用する

オプション 2: IP リストを使用する

SQL Azure の IP ファイアウォール例外を構成する

大規模なコレクションを移行する

コレクションサイズを小さくできるかどうかを判断する

サイズの制限

Azure DevOps Services に移行するように SQL Azure VM を設定する

SQL Azure VM を設定する

VM でデータベースを復元する

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

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

選択したデータセンターに Azure Storage コンテナーを作成する

請求の設定

次のステップ

フィードバック

フィードバック

その他のリソース

次の方法で共有

テスト実行移行の準備

前提条件

移行設定を生成する

移行仕様ファイルを構成する

ID マップ ログ ファイルを確認する

アクティブな ID

履歴 ID

ライセンス

Azure DevOps サブスクリプション

Azure DevOps Services IP のみにアクセスを制限する

オプション 1: サービス タグを使用する

オプション 2: IP リストを使用する

SQL Azure の IP ファイアウォール例外を構成する

大規模なコレクションを移行する

コレクション サイズを小さくできるかどうかを判断する

サイズの制限

Azure DevOps Services に移行するように SQL Azure VM を設定する

SQL Azure VM を設定する

VM でデータベースを復元する

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

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

選択したデータ センターに Azure Storage コンテナーを作成する

請求の設定

次のステップ

関連記事

フィードバック

フィードバック

その他のリソース

ID マップログファイルを確認する

オプション 1: サービスタグを使用する

コレクションサイズを小さくできるかどうかを判断する

選択したデータセンターに Azure Storage コンテナーを作成する