検証プロセスとインポート プロセス
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
この記事では、Azure DevOps Services へのインポートを実行する準備を行うために必要な準備について説明します。 プロセス中にエラーが発生した場合は、「 インポートと移行のエラーのトラブルシューティング」を参照してください。
前提条件
- 「Microsoft Entra Connect Sync: 既定の構成に変更を加える」の説明に従って、Microsoft Entra テナントを設定する必要があります。 データ移行ツールは、インポート プロセスの開始時に Azure DevOps Services 組織が作成されるときに、Microsoft Entra テナントへのリンクを設定します。 オンプレミスの Active Directoryを Microsoft Entra ID と同期すると、チーム メンバーは同じ資格情報を使用して認証を行い、Azure DevOps Services 管理者は Active Directory グループを使用して Azure DevOps Services 組織内のアクセス許可を設定できます。 同期を設定するには、Microsoft Entra Connect テクノロジを使用します。
- インポート タスクを開始する前に、サポートされているバージョンのAzure DevOps Serverを実行していることを確認チェック。
- インポートを進めるために、 ステップ バイ ステップの移行ガイド を使用することをお勧めします。 このガイドは、技術ドキュメント、ツール、ベスト プラクティスにリンクしています。
コレクションを検証する
Azure DevOps Services に移行する各コレクションを検証します。 検証手順では、サイズ、照合順序、ID、プロセスなど、コレクションのさまざまな側面を調べますが、これらに限定されません。
データ移行ツールを使用して検証を実行します。
zip ファイルを Azure DevOps Server アプリケーション層のいずれかにコピーする
ファイルを解凍します。 マシンが Azure DevOps Server インスタンスの構成データベースに接続できる限り、Azure DevOps Server がインストールされていない別のコンピューターからツールを実行することもできます。
サーバーでコマンド プロンプト ウィンドウを開き、cd コマンドを入力して、データ移行ツールが格納されているディレクトリに変更します。 少し時間を取って、ツールのヘルプ コンテンツを確認してください。
a. 最上位のヘルプとガイダンスを表示するには、次のコマンドを実行します。
Migrator /helpb. コマンドのヘルプ テキストを表示します。
Migrator validate /helpコレクションを初めて検証する際は、単純にしましょう。 コマンドの構造は次のとおりです。
Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}ここでは
{name}、DefaultCollection と fabrikam テナントに対して実行する Microsoft Entra テナントの名前を指定します。このコマンドは次の例のようになります。Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}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"重要
データ移行ツール では、 コレクション内のデータまたは構造体は編集されません。 コレクションは、問題を特定するためにのみ読み取られます。
検証が完了したら、ログ ファイルと結果を表示できます。
検証中に、一部のパイプラインにパイプラインごとの保持ルールが含まれている場合、警告が表示されます。 Azure DevOps Services では、プロジェクト ベースの保持モデルが使用され、パイプラインごとの保持ポリシーはサポートされません。 移行を続行した場合、ポリシーはホストされているバージョンに引き継がれられません。 代わりに、既定のプロジェクト レベルのアイテム保持ポリシーが適用されます。 ビルドの損失を回避するために重要なビルドを保持します。
すべての検証に合格したら、インポート プロセスの次の手順に進むことができます。 データ移行ツールでエラーにフラグが設定されている場合は、先に進む前に修正してください。 検証エラーの修正に関するガイダンスについては、「 インポートと移行のエラーのトラブルシューティング」を参照してください。
ログ ファイルをインポートする
ログ ディレクトリを開くと、いくつかのログ ファイルが表示されることがあります。
メインログ ファイルの名前は DataMigrationTool.log です。 これには、実行されたすべてのものに関する詳細が含まれています。 特定の領域に集中しやすくするために、主要な検証操作ごとにログが生成されます。
たとえば、TfsMigrator が "プロジェクト プロセスの検証" ステップでエラーを報告した場合は、 ProjectProcessMap.log ファイルを開いて、ログ全体をスクロールするのではなく、その手順で実行されたすべてを表示できます。
継承されたモデルを使用するためにプロジェクト プロセスをインポートしようとしている場合にのみ、TryMatchOobProcesses.log ファイルを確認します。 継承されたモデルを使用しない場合は、Azure DevOps Services へのインポートを妨げるので、これらのエラーは無視できます。
インポート ファイルを生成する
データ移行ツールによってコレクションが検証され、"すべてのコレクション検証に合格しました" という結果が返されます。コレクションをオフラインにして移行する前に、インポート ファイルを生成します。 コマンドを実行すると、次の prepare 2 つのインポート ファイルが生成されます。
- IdentityMapLog.csv: Active Directory と Microsoft Entra ID の間の ID マップの概要を示します。
- import.json: 移行を開始するために使用するインポート仕様を入力する必要があります。
Prepare コマンド
コマンドは prepare 、必要なインポート ファイルの生成を支援します。 基本的に、このコマンドはコレクションをスキャンして、すべてのユーザーの一覧を検索して ID マップ ログに入力し、 IdentityMapLog.csvし、Microsoft Entra ID に接続して各 ID の一致を見つけようとします。 そのためには、Microsoft Entra Connect ツール (旧称ディレクトリ同期ツール、ディレクトリ同期ツール、またはDirSync.exe ツール) を使用する必要があります。
ディレクトリ同期が設定されている場合、データ移行ツールは一致する ID を見つけてアクティブとしてマークする必要があります。 一致しない場合、ID は ID マップ ログで履歴としてマークされるため、ユーザーがディレクトリ同期に含まれていない理由を調査する必要があります。インポート仕様ファイルimport.jsonは、インポートの前に設定する必要があります。
validateコマンドとは異なり、prepareID マップ ログ ファイルを設定するには 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 サインイン ウィンドウが表示されます。 コマンドで指定されたテナント doメイン に属する ID を使用してサインインします。 指定した Microsoft Entra テナントが、将来の組織でサポートされるテナントであることを確認します。 Fabrikam の例では、ユーザーは次のスクリーンショットの例のような資格情報を入力します。
重要
テスト インポートにはテスト Microsoft Entra テナントを使用し、運用環境の実行には運用環境の Microsoft Entra テナントを使用しないでください。 Microsoft Entra テナントのテストを使用すると、組織の運用 Microsoft Entra テナントで運用の実行を開始するときに、ID インポートの問題が発生する可能性があります。
データ移行ツールでコマンドを prepare 正常に実行すると、結果ウィンドウに一連のログと 2 つのインポート ファイルが表示されます。 ログ ディレクトリで、ログ フォルダーと 2 つのファイルを見つけます。
- import.json はインポート仕様ファイルです。 時間をかけて記入することをお勧めします。
- IdentityMapLog.csvには、生成された Active Directory から Microsoft Entra ID へのマッピングが含まれています。 インポートを開始する前に、完全さを確認してください。
2 つのファイルについては、次のセクションで詳しく説明します。
インポート仕様ファイル
import 仕様 import.json は、インポート設定を提供する JSON ファイルです。 これには、目的のorganization名、ストレージ アカウント情報、およびその他の情報が含まれます。 ほとんどのフィールドは自動入力され、インポートを試みる前に入力が必要なフィールドもあります。
import.json ファイルに表示されるフィールドと必要なアクションについて、次の表で説明します。
| フィールド | 説明 | 必要なアクション |
|---|---|---|
| source | インポートに使用されるソース データ ファイルの場所と名前に関する情報。 | 必要なアクションはありません。 従うサブフィールド アクションの情報を確認します。 |
| 場所 | データ層アプリケーション パッケージ (DACPAC) をホストする Azure ストレージ アカウントへの共有アクセス署名キー。 | 必要なアクションはありません。 このフィールドについては、後の手順で説明します。 |
| ファイル | インポート データを含むファイルの名前。 | 必要なアクションはありません。 従うサブフィールド アクションの情報を確認します。 |
| DACPAC | インポート中にデータを取り込む際に使用するコレクション データベースをパッケージする DACPAC ファイル。 | 必要なアクションはありません。 後の手順では、コレクションを使用してこのファイルを作成し、Azure ストレージ アカウントにアップロードします。 このプロセスの後半で生成するときに使用する名前に基づいてファイルを更新します。 |
| 移行先 | インポート先の新しいorganizationのプロパティ。 | 必要なアクションはありません。 従うサブフィールド アクションの情報を確認します。 |
| 名前 | インポート中に作成するorganizationの名前。 | 名前を指定します。 名前は、インポートが完了した後ですぐに変更できます。 注: インポートを実行する前に、この名前の組織を作成しないでください 。 組織は、インポート プロセスの一部として作成されます。 |
| ImportType | 実行するインポートの種類。 | 必要なアクションはありません。 後の手順で、実行するインポートの種類を選択します。 |
| 検証データ | インポート エクスペリエンスを促進するために必要な情報。 | データ移行ツールでは、"ValidationData" セクションが生成されます。 これには、インポート エクスペリエンスを促進するのに役立つ情報が含まれています。 このセクションの値を編集しない* か、インポートの開始に失敗する可能性があります。 |
上記のプロセスを完了すると、次の例のようなファイルが作成されます。
前の図では、Fabrikam インポートのプランナーが組織名 fabrikam-import を追加し、インポートの地理的な場所として CUS (中央米国) を選択しました。 その他の値は、プランナーが移行のためにコレクションをオフラインにする直前に変更されるように残されていました。
Note
ドライラン インポートでは、組織名の末尾に "-dryrun" が自動的に追加されます。これは、インポート後に変更できます。
インポートでサポートされている 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 は 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 を使用することをお勧めします。
Note
ID が履歴としてインポートされた後は、アクティブに することはできません 。
ID マップ ログ ファイルを理解する
ID マップ ログ ファイルは、次に示す例のようになります。
ID マップ ログ ファイルの列を次の表に示します。
お客様と Microsoft Entra 管理者は、一致が見つからない (Microsoft Entra ID Sync を確認してください) としてマークされたユーザーを調査して、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 Directory と Microsoft Entra ID の間に一致する場合はアクティブか、 一致しない場合は履歴 です。 |
| 検証日 | ID マップ ログが最後に検証された時刻。 |
ファイルを読み進める際に、[ 予期されるインポート状態] 列の値が [アクティブ ] または [履歴] のどちらであるかに注意してください。 アクティブ は、インポート時にこの行の ID が正しくマップされることを示します。 履歴 とは、インポート時に ID が履歴になることを意味します。 生成されたマッピング ファイルの完全性と正確性を確認することが重要です。
重要
インポートの試行間に Microsoft Entra Connect セキュリティ ID 同期に大きな変更が発生した場合、インポートは失敗します。 ドライ ランの間に新しいユーザーを追加し、以前にインポートした履歴 ID がアクティブになるように修正することができます。 ただし、以前にアクティブとしてインポートされた既存のユーザーの変更は、現時点ではサポートされていません。 これにより、インポートが失敗します。 変更の例としては、ドライラン インポートの完了、アクティブにインポートされた Microsoft Entra ID からの ID の削除、その同じ ID に対する Microsoft Entra ID での新しいユーザーの再作成、別のインポートの試行などが考えられます。 この場合、Active Directory と新しく作成された Microsoft Entra ID の間でアクティブな ID のインポートが試行されますが、インポートエラーが発生します。
正しく一致する ID を確認します。 すべての予想される ID が存在しますか? ユーザーは正しい Microsoft Entra ID にマップされていますか?
値を変更する必要がある場合は、Microsoft Entra 管理者に連絡して、オンプレミスの Active Directory ID が Microsoft Entra ID との同期の一部であり、正しく設定されていることを確認してください。 詳細については、「オンプレミス ID と Microsoft Entra ID の統合」を参照してください。
次に、 履歴としてラベル付けされている 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 を設定します。 詳細については、「オンプレミス ID と Microsoft Entra ID の統合」を参照してください。 Azure DevOps Services でアクティブとして ID をインポートするには、Microsoft Entra Connect を設定して実行する必要があります。
会社にいなくなった従業員は 履歴としてインポートする必要があるため、4 番目の理由は無視できます。
履歴 ID (小規模チーム)
注意
このセクションで提案されている ID インポート戦略は、小規模なチームでのみ考慮する必要があります。
Microsoft Entra Connect が構成されていない場合、ID マップ ログ ファイル内のすべてのユーザーは履歴としてマークされます。 この方法でインポートを実行すると、すべてのユーザーが 履歴としてインポートされます。 ユーザーがアクティブとしてインポートされるように Microsoft Entra Connect を構成することを強くお勧めします。
すべての履歴 ID でインポートを実行すると、慎重に考慮する必要があります。 Microsoft Entra Connect を設定するコストが高すぎると見なされるユーザーが少ないチームのみが考慮する必要があります。
すべての ID を履歴としてインポートするには、後のセクションで説明する手順に従います。 インポートをキューに登録すると、インポートのキューに使用される ID が組織の所有者として組織にブートストラップされます。 他のすべてのユーザーは履歴としてインポートされます。 組織 の所有者は、Microsoft Entra ID を使用してユーザーを再度 追加できます。 追加されたユーザーは、新しいユーザーとして扱われます。 彼らは自分の歴史を*所有していませんし、この履歴を Microsoft Entra ID に親しむ方法はありません。 ただし、ユーザーは doメインActive Directory ユーザー名>を検索することで、><引き続きプリインポート履歴を検索<できます。
データ移行ツールは、完全な履歴 ID シナリオを検出すると警告を表示します。 この移行パスを下に移動する場合は、ツールで制限事項に同意する必要があります。
Visual Studio サブスクリプション
データ移行ツールは、ID マップ ログ ファイルを生成するときに、Visual Studio サブスクリプション (旧称 MSDN 特典) を検出できません。 代わりに、インポート後に自動ライセンス アップグレード機能を適用することをお勧めします。 ユーザーの職場アカウントが正しくリンクされている限り、Azure DevOps Servicesインポート後の最初のサインイン時に Visual Studio サブスクリプションの特典が自動的に適用されます。 インポート中に割り当てられたライセンスに対して課金されることはありません。そのため、後でサブスクリプションを安全に処理できます。
ユーザーの Visual Studio サブスクリプションがAzure DevOps Servicesで自動的にアップグレードされない場合は、ドライラン インポートを繰り返す必要はありません。 Visual Studio サブスクリプションのリンクは、インポートの範囲外で行われます。 インポート前またはインポート後に職場アカウントが正しくリンクされている限り、ユーザーのライセンスは次回のサインイン時に自動的にアップグレードされます。 ライセンスが正常にアップグレードされると、次回インポートを実行すると、ユーザーは組織への最初のサインイン時に自動的にアップグレードされます。
インポートの準備
これで、インポートで実行できる準備がすべて整いました。 移行のためにコレクションをオフラインにするように、チームでダウンタイムをスケジュールします。 インポートを実行する時間に同意したら、生成した必要な資産とデータベースのコピーを Azure にアップロードします。 インポートの準備は、次の 5 つの手順で構成されます。
手順 1: コレクションをオフラインにしてデタッチします。
DACPAC メソッドのコレクション サイズ制限は 150 GB です。 DACPAC メソッドを使用できないという警告がデータ移行ツールに表示される場合は、SQL Azure仮想マシン (VM) メソッドを使用してインポートを実行する必要があります。 その場合は手順 2 から 5 をスキップし、「 大きなコレクションをインポート する」に記載されている手順に従い、 インポートの種類を決定するセクションに進みます。
手順 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 メソッドを使用できないという警告がデータ移行ツールに表示される場合は、「大規模なコレクションをインポートする」で提供されているSQL Azure仮想マシン (VM) メソッドを使用してインポートを実行する必要があります。
データ移行ツールに警告が表示されない場合は、この手順で説明する DACPAC メソッドを使用します。
DACPAC は、データベースを 1 つのファイルにパッケージ化し、SQL Server の他のインスタンスにデプロイできるようにする SQL Server の機能です。 DACPAC ファイルはAzure DevOps Servicesに直接復元することもできます。そのため、クラウドでコレクションのデータを取得するためのパッケージ化方法として使用できます。
重要
- SqlPackage.exeを使用する場合は、.NET Framework バージョンのSqlPackage.exeを使用して DACPAC を準備する必要があります。 MSI インストーラーを使用して、.NET Framework バージョンのSqlPackage.exeをインストールする必要があります。 dotnet CLI または .zip (Windows .NET 6) バージョンのSqlPackage.exeを使用しないでください。これらのバージョンでは、Azure DevOps Services と互換性のない DACPAC が生成される可能性があるためです。
- バージョン 161 の SqlPackage では、既定でデータベース接続が暗号化され、接続されない場合があります。 ログイン プロセス エラーが発生した場合は、SqlPackage ステートメントの接続文字列に追加
;Encrypt=False;TrustServerCertificate=Trueします。
SqlPackage リリース ノートから最新の MSI インストーラーを使用して、SqlPackage.exeをダウンロードして インストールします。
MSI インストーラーを使用した後、次のような %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\パスSqlPackage.exeインストールされます。
DACPAC を生成するときは、DACPAC が保存されているディスクと、DACPAC を生成するコンピューター上のディスク領域という 2 つの考慮事項に注意してください。 操作を完了するのに十分なディスク領域があることを確認する必要があります。
パッケージが作成されると、SqlPackage.exeは、パッケージ化要求を開始するコンピューターのドライブ C の一時ディレクトリにコレクションのデータを一時的に格納します。
ドライブ C が小さすぎて DACPAC の作成がサポートされていない場合があります。 コレクション データベースで最大のテーブルを検索することで、必要な領域の量を見積もることができます。 DACPAC は、一度に 1 つのテーブルで作成されます。 生成を実行するための最大領域要件は、コレクションのデータベース内の最大テーブルのサイズとほぼ同じです。 生成された DACPAC をドライブ C に保存する場合は、検証の実行からDataMigrationTool.log ファイルで報告されるコレクション データベースのサイズを検討してください。
DataMigrationTool.log ファイルには、コマンドを実行するたびに、コレクション内の最大のテーブルの一覧が表示されます。 コレクションのテーブル サイズの例については、次の出力を参照してください。 最大テーブルのサイズと、一時ディレクトリをホストするドライブ上の空き領域を比較します。
重要
DACPAC ファイルの生成に進む前に、コレクションが デタッチされていることを確認してください。
[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.dacpac という名前のコレクション データベース Foo から生成されます。
インポート用にコレクションを構成する
コレクション データベースが 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>'
Fabrikam の例に従って、2 つの 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'
Note
VM でSQL Server Management StudioでSQL ServerモードとWindows 認証モードを有効にしてください。 認証モードを有効にしない場合、インポートは失敗します。
VM をターゲットにするようにインポート仕様ファイルを構成する
インポート仕様ファイルを更新して、SQL Server インスタンスへの接続方法に関する情報を含めます。 インポート仕様ファイルを開き、次の更新を行います。
ソース ファイル オブジェクトから DACPAC パラメーターを削除します。
変更前のインポート仕様を次のコードに示します。
変更後のインポート仕様を次のコードに示します。
必要なパラメーターを入力し、ソース オブジェクト内の次の 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 ファイルをアップロードする
注意
SQL Azure VM メソッドを使用している場合は、接続文字列のみを指定する必要があります。 ファイルをアップロードする必要はありません。この手順は省略できます。
DACPAC は Azure ストレージ コンテナーに配置する必要があります。これは、既存のコンテナーでも、移行作業専用に作成されたものでもかまいません。 コンテナーが適切な地理的な場所に作成されるようにすることが重要です。
Azure DevOps Services は、複数 の地理的な場所で利用できます。 これらの場所にインポートするときは、インポートを正常に開始できるようにデータを正しく配置することが重要です。 データは、インポート先と同じ地理的な場所に配置する必要があります。 データを他の場所に配置すると、インポートを開始できません。 次の表に、ストレージ アカウントの作成とデータのアップロードに使用できる地理的な場所を示します。
| 必要なインポートの地理的な場所 | ストレージ アカウントの地理的な場所 |
|---|---|
| 中央米国 | 中央米国 |
| 西ヨーロッパ | 西ヨーロッパ |
| イギリス | イギリス南部 |
| オーストラリア東部 | オーストラリア東部 |
| ブラジル南部 | ブラジル南部 |
| インド南部 | インド南部 |
| カナダ中部 | カナダ中部 |
| アジア太平洋 (シンガポール) | アジア太平洋 (シンガポール) |
Azure DevOps Services は米国内の複数の地理的な場所で利用できますが、新しい Azure DevOps Services を受け入れるのは中央米国の場所のみです。 現時点では、他の米国の Azure の場所にデータをインポートすることはできません。
blob コンテナーは、Azure portalから作成できます。 コンテナーを作成したら、コレクション DACPAC ファイルをアップロードします。
インポートが完了したら、AzCopy などのツールまたは Azure Storage エクスプローラー などの他の Azure Storage エクスプローラー ツールを使用して、BLOB コンテナーと付随するストレージ アカウントを削除します。
Note
DACPAC ファイルが 10 GB を超える場合は、AzCopy を使用することをお勧めします。 AzCopy では、アップロードを高速化するためのマルチスレッドアップロードがサポートされています。
手順 4: SAS トークンを生成する
Shared Access Signature (SAS) トークンは、ストレージ アカウント内のリソースへの委任されたアクセスを提供します。 このトークンを使用すると、インポートを実行するためにデータにアクセスするために必要な最小レベルの特権を Microsoft に付与できます。
SAS トークンは、Azure portal を使用して生成できます。 セキュリティの観点から、次のことをお勧めします。
- SAS トークンのアクセス許可として [読み取り] と [一覧表示] のみを選択します。 その他のアクセス許可は必要ありません。
- 有効期限を 7 日以内に設定します。
- Azure DevOps Services IP にのみアクセスを制限します。
- SAS トークンを安全な場所に配置します。
手順 5: インポートの仕様を完了する
プロセスの前半で、インポート仕様ファイル (import.json と呼ばれます) を部分的に入力しました。 この時点で、インポートの種類を除く残りのすべてのフィールドを完了するのに十分な情報があります。 インポートの種類については、後の「インポート」セクションで説明します。
import.json仕様ファイルの [ソース] で、次のフィールドに入力します。
- 場所: スクリプトから生成した SAS キーを貼り付け、前の手順でコピーしました。
- Dacpac: .dacpac ファイル拡張子を含むファイルの名前が、ストレージ アカウントにアップロードした DACPAC ファイルと同じであることを確認します。
最終的なインポート仕様ファイルは、次の例のようになります。
Azure DevOps Services IP のみにアクセスを制限する
詳細については、「Azure DevOps Services IP のみにアクセスを制限する」を参照してください。
オプション 1: サービス タグの使用
ポータルまたはプログラムを使用して、ネットワーク セキュリティ グループまたはファイアウォールにサービス タグをazuredevops追加することで、すべての Azure DevOps Services 地理的な場所からの接続を簡単に許可できます。
オプション 2: IpList の使用
このコマンドを IpList 使用して、特定の Azure DevOps Services の地理的な場所からの接続を許可するためにアクセス権を付与する必要がある IP の一覧を取得します。
ヘルプ ドキュメントには、Azure DevOps Server インスタンス自体とリモート コンピューターから Migrator を実行するための手順と例が含まれています。 Azure DevOps Server インスタンスのいずれかのアプリケーション層からコマンドを実行している場合、コマンドの構造は次のようになります。
Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}
IP の一覧は、ポータルまたはプログラムを使用して、ネットワーク セキュリティ グループまたはファイアウォールに追加できます。
インポートの種類を決定する
インポートは、ドライ ランまたは運用実行としてキューに登録できます。 ImportType パラメーターは、インポートの種類を決定します。
- DryRun: テスト目的でドライ ランを使用します。 システムは、21 日後にドライ ランを削除します。
- ProductionRun: 結果のインポートを保持し、インポートの完了後にAzure DevOps Servicesでorganizationをフルタイムで使用する場合は、運用実行を使用します。
ヒント
最初にドライランインポートを完了することをお勧めします。
ドライラン組織
ドライランインポートは、チームがコレクションの移行をテストするのに役立ちます。 組織は永遠に留まらず、短時間存在することが期待されています。 実際、運用移行を実行する前に、完了したドライラン組織を削除する必要があります。 ドライラン組織はすべて 存在が限られており、一定時間後に自動的に削除されます。 組織が削除されるタイミングに関する情報は、インポートの完了後に受信する必要がある成功メールに含まれます。 この日付をメモし、それに応じて計画してください。
ほとんどのドライラン組織は、削除されるまでに 15 日かかります。 ドライラン組織は、 インポート時に 100 人を超えるユーザーが基本以上のライセンスを持っている場合、21 日間の有効期限を設定することもできます。 指定した期間が経過すると、ドライラン organizationが削除されます。 運用移行を行う前に、必要な回数だけドライラン インポートを繰り返すことができます。 新しいドライランを試みる前に、以前のドライランをすべて削除する必要があります。 チームが運用環境への移行を実行する準備ができたら、ドライラン組織を手動で削除する必要があります。
インポート後のアクティビティの詳細については、 インポート後 の記事を参照してください。
インポートの問題が発生した場合は、「 インポートと移行のエラーのトラブルシューティング」を参照してください。
インポートを実行する
これで、チームはインポートを実行するプロセスを開始する準備ができました。 実稼働インポートを試みる前に、ドライラン インポートを正常に開始することをお勧めします。 ドライラン インポートでは、インポートの外観を事前に確認し、潜在的な問題を特定し、運用を開始する前にエクスペリエンスを得ることができます。
Note
- ロールバックの場合と同様に、コレクションに対して完了した実稼働インポートを繰り返す必要がある場合は、別のインポートをキューに登録する前Azure DevOps Servicesカスタマー サポートにお問い合わせください。
- Azure 管理者は、ユーザーが新しい Azure DevOps 組織を作成できないようにすることができます。 Microsoft Entra テナント ポリシーが有効になっている場合、インポートは完了しません。 開始する前に、ポリシーが設定されていないこと、または移行を実行しているユーザーに例外があることを確認します。 詳細については、「Microsoft Entra テナント ポリシーを使用して組織の作成を制限する」を参照してください。
- Azure DevOps Services では、パイプラインごとの保持ポリシーはサポートされておらず、ホストされているバージョンに引き継がれることはありません。
ロールバック 計画に関する考慮事項
最終的な運用実行を行うチームの一般的な懸念事項は、インポートに問題がある場合のロールバック計画です。 ドライ ランを実行して、Azure DevOps のデータ移行ツールに提供するインポート設定をテストできることを確認することを強くお勧めします。
最終的な運用実行のロールバックは非常に簡単です。 インポートをキューに入れる前に、チーム プロジェクト コレクションを Azure DevOps Server からデタッチします。これにより、チーム メンバーが使用できなくなります。 何らかの理由で運用実行をロールバックし、オンプレミス サーバーをチーム メンバーのためにオンラインに戻す必要がある場合は、これを行うことができます。 チーム プロジェクト コレクションをもう一度オンプレミスにアタッチし、チームが再グループ化して潜在的な障害を把握している間も正常に動作することをチームに通知します。
インポートをキューに入れる
重要
先に進む前に、DACPAC ファイルを生成するか、コレクション データベースをSQL Azure VM にアップロードする前に、コレクションがデタッチされていることを確認します。 この手順を完了しないと、インポートは失敗します。 インポートが失敗した場合は、「 インポートと移行のエラーのトラブルシューティング」を参照してください。
データ移行ツールの import コマンドを使用してインポートを開始します。 import コマンドは、インポート仕様ファイルを入力として受け取ります。 ファイルを解析して、指定された値が有効であることを確認し、成功した場合はインポートをキューに入Azure DevOps Services。 インポート コマンドにはインターネット接続が必要ですが、Azure DevOps Server インスタンスへの接続は必要ありません*。
作業を開始するには、コマンド プロンプト ウィンドウを開き、ディレクトリをデータ移行ツールのパスに変更します。 ツールで提供されるヘルプ テキストを確認することをお勧めします。 次のコマンドを実行して、import コマンドのガイダンスとヘルプを確認します。
Migrator import /help
インポートをキューに入れるコマンドの構造は次のとおりです。
Migrator import /importFile:{location of import specification file}
次の例は、完了したインポート コマンドを示しています。
Migrator import /importFile:C:\DataMigrationToolFiles\import.json
検証に合格すると、Microsoft Entra ID にサインインするように求められます。 ID マップ ログ ファイルが作成されたのと同じ Microsoft Entra テナントのメンバーである ID を使用してサインインすることが重要です。 サインインしているユーザーは、インポートされた組織の所有者です。
Note
各 Microsoft Entra テナントは、24 時間ごとに 5 つのインポートに制限されます。 この上限に対してキューに登録された数のインポートのみ。
チームがインポートを開始すると、インポートをキューに入れたユーザーに電子メール通知が送信されます。 インポートをキューに入れる約 5 分から 10 分後に、チームはorganizationに移動して状態をチェックできます。 インポートが完了すると、チームはサインインするように指示され、organization所有者に電子メール通知が送信されます。
関連記事
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示