テスト実行移行の準備

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

前提条件

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

移行設定を生成する

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

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

   /collection:http://localhost:8080/tfs/DefaultCollection/ tenantDomainName:contoso.com /Region:CUS

   • テナント ドメイン名オプションは、会社の Microsoft Entra ID テナントの名前です。
   • prepare コマンドにはインターネット アクセスが必要です。 Azure DevOps Server にインターネット接続がない場合は、別のコンピューターからコマンドを実行します。
   • "組織リージョン" という用語は、コレクションを Azure DevOps Services に移行する予定の場所を指します。 以前にリージョンを選択し、その短縮コードを記録しました。 prepare コマンドでこのコードを使用します。

2. Microsoft Entra ID テナント内のすべてのユーザーに関する情報を読み取るアクセス許可を持つテナントのユーザーを使用してサインインします。

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

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

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

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

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

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

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

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

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

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

Azure DevOps サブスクリプション

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

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

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

• オプション 1: サービス タグを使用する
• オプション 2: IP リストを使用する

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 に例外を付与するには、次の手順を実行します。

1. Azure portal にサインインします。
2. SQL Azure VM に移動します。
3. [設定] の [ネットワーク] を選択します。
4. [受信ポートの規則を追加する] を選択します。
5. 特定の IP の受信ポート規則を構成するには、[詳細設定] を選択します。
6. [送信元] ドロップダウン リストで、[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) を設定するには、次の大まかな手順を実行します。

1. SQL Azure VM を設定する
2. IP ファイアウォールの例外を構成する
3. VM でデータベースを復元する
4. [移行用にコレクションを構成する
5. 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 を間違った場所に設定した場合、移行の開始に失敗します。

この移行方法を使用している場合は、サポートされているリージョンに VM を作成します。 Azure DevOps Services は 米国 (米国) の複数のリージョンで利用できますが、新しい組織を受け入れるのは中央米国 リージョンのみです。 現在、他の米国の 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 サインインを構成します。 このサインインでは、単一データベースへの読み取りアクセスのみが許可されます。

1. VM で SQL Server Management Studio を開き、移行するデータベースに対して新しいクエリ ウィンドウを開きます。

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

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

3. 次の例のように、データベースの 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>'
   

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

    ALTER DATABASE [Foo] 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": 
   { 
       "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 サインインを削除するか、パスワードをローテーションしてください。 Microsoft は、移行が完了した後もサインイン情報を保持しません。

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

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

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

請求の設定

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

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

次のステップ

関連記事

• Azure DevOps Services への移行
• 移行後のタスクを完了する