Azure DevOps Data Migration Tool を使用して、忠実度の高いデータベースを移行する前に、この記事の基本的な概念について説明します。
![[作業の開始] ステージを順番に強調表示した図。](media/get-started-stage-migration-highres.png?view=azure-devops)
移行されるデータについて説明します
すべてのデータが移行されるわけではありません。 レポートデータやSharePointデータなど、コレクション外のデータベースを分離しても、移行されません。 次のセクションでは、移行されるデータの詳細を示します。
含まれているデータ
次の表に、移行に含まれるデータを示します。
| 含まれているデータ | 説明 |
|---|---|
| コレクション マッピング | Azure DevOps Server の各コレクションは、1 つのデータベースに対応します。 移行中、作業項目、履歴、Team Foundation Version Control (TFVC) 変更セット、Git データ、ビルド定義など、コレクション全体が Azure DevOps Services に移行されます。 作業項目、TFVC 変更セット、Git コミット番号/ID は変更されません。 |
除外されたデータ
次の表に、移行における特定のデータ除外を示します。
| 除外されたデータ | 説明 |
|---|---|
| 拡張機能 | 移行後に拡張機能を再インストールする必要があります。 ローカル拡張機能をプライベート拡張機能として Marketplace に公開し、アカウントと共有します。 |
| サービス フック | サービス フック データは移行に含まれません。 移行後に再構成します。 |
| 負荷テスト (ロードテスト) | ロード テスト データは引き継がれない。 移行後にロード テストを再構成します。 |
| パイプライン エージェントとエージェント プール | 移行後にパイプライン エージェントとエージェント プールを再構成します。 |
| メンション | 作業項目ディスカッション内のユーザーメンションは、新しい Microsoft Entra ID ではなく、オンプレミスの ID を保持します。 ユーザー名をポイントしても連絡先カードは表示されません。一部のハイパーリンクが無効な場合があります。 |
| Project Server の統合 | Azure DevOps Services では使用できません。 たとえば、XAML ビルド、Microsoft Test Manager、SharePoint、SQL Data Warehouse などです。 |
| プレビュー機能 | Azure DevOps Server の一部の機能は、Azure DevOps Services への移行中にプレビューできます。 |
プロジェクトの制限
コレクションに多数のプロジェクトが含まれている場合、Azure DevOps Services では 1 組織あたり 1,000 プロジェクトの制限が課されますが、推奨されるプロジェクトは 300 個以下です。 このしきい値を超えると、Visual Studioから組織に接続するなど、特定のエクスペリエンスが低下する可能性があります。 制限内に収まるようにするには、コレクションを分割するか、古いプロジェクトを削除することを検討してください。
オンプレミス データベースと Azure DevOps 組織の関係を理解します。
移行の計画について深く掘り下げすぎる前に、データベース移行プロセスがどのように機能するかを管理者特権で理解しておくことが重要です。 移行は、次の主要な概念に基づいて動作します。
- チーム プロジェクト コレクション: Azure DevOps Server のコレクションは、チーム プロジェクトとその成果物の物理コンテナーです。 各コレクションは 1 つの SQL データベースに相当し、Azure DevOps Services への移行のソースです。
-
Azure DevOps Services 組織: 組織は、クラウドでホストされるサービスの管理単位です。 論理的には、1:1 は Azure DevOps Server のチーム プロジェクト コレクションの概念にマップされます。 そのため、組織は Azure DevOps Services への移行先となります。 たとえば、Azure DevOps Services 組織は、Contoso が Azure DevOps Services 組織の名前を表す
https://dev.azure.com/Contosoとして表されます。
チーム プロジェクト コレクション SQL データベースを移行すると、データ移行ツールによって、ユーザー指定の名前を持つ新しい Azure DevOps 組織が作成されます。 コレクション データベースを既存の Azure DevOps Services 組織に移行したり、複数のコレクション データベースを 1 つの Azure DevOps Services 組織に統合したりすることはできません。 マッピングは、チーム プロジェクト コレクションと Azure DevOps Services 組織の間で厳密に 1 対 1 です。
データ センターの選択
Azure DevOps サービス組織を設定するときに、データの場所を選択します。 最初のサインアップと組織の作成中に、ニーズに合ったリージョンを選択します。 後で移行に使用するには、リージョンの短縮コードを書き留めておきます。
Von Bedeutung
すべての Azure リージョンでデータ移行ツールがサポートされているわけではありません。 サポートされていないリージョンで一時的な SQL VM またはその他の移行インフラストラクチャを設定すると、遅延が発生し、再構成が必要になる可能性があります。 移行計画に進む前に、サポートされているリージョンを確認してください。
移行でサポートされている Azure リージョン
次の表に、Azure DevOps データ移行ツールをサポートする Azure リージョンを示します。
| リージョン | 短縮コード |
|---|---|
| 米国中部 | CUS |
| 西ヨーロッパ | 私たち |
| イギリス南部 | UKS |
| オーストラリア東部 | AE |
| ブラジル南部 | BS |
| インド中部 | MA |
| 東南アジア (シンガポール) | 海 |
| カナダ中部 | CC |
移行プロセス全体と、リージョンに関する最新の考慮事項については、移行でサポートされている Azure リージョンを参照してください。
価格について理解する
移行に関する一般的な質問は、会社が Azure DevOps Services を使用する必要があるライセンスの種類です。 良いニュースは、必要なすべてのライセンスを既に持っている可能性が高いということです。 ほとんどの場合に対応するワークシートの例を使用できます。 状況に関する具体的な質問がある場合は、開発者ソリューション販売スペシャリストまたは Microsoft リセラーにお問い合わせください。 詳細については、「Pricing for Azure DevOps」を参照してください。
ユーザー ライセンス ワークシート
| # | 列 1 | 列 2 |
|---|---|---|
| 1 | チーム メンバーの数 | |
| 2 | 利害関係者の数 | |
| 3 | 行 2 の値を 1 行目の値から減算します* | |
| 4 | Visual Studioサブスクライバー数** | |
| 5 | 4 行目の値を 3 行目の値から減算します。 | |
| 6 | 5 行目の値を 5 行目の値から減算します*** |
- *関係者は無料です。
- ** Visual Studioサブスクライバーには、サブスクリプションの特典としてAzure DevOpsサービスが含まれています。
- 各Azure DevOps サービス組織には、5 人の無料ユーザーが付与されます。
機能にアクセスするためのコスト効率の高いオプションの詳細については、「 Billing の概要 および Azure 料金計算ツールを参照してください。
Visual Studio Marketplace または Azure portal を使用して、必要な Azure DevOps Services ユーザー ライセンスを購入します。 このプロセスは、 テスト実行の準備フェーズで説明します。
コア機能に加えて、Azure DevOps では次の付加価値サービスを利用できます。役に立つ可能性があります。
- ホスト型ロード テスト サービス: 負荷の下にあるアプリケーションのパフォーマンスをシミュレートして分析する必要がある場合、Azure DevOps はホスト型ロード テスト サービスを提供します。 これらのサービスを使用すると、アプリケーションをストレス テストし、ボトルネックやパフォーマンスの問題を特定できます。
- テスト マネージャー拡張機能: 包括的なテスト管理を行う場合は、Test Manager 拡張機能の使用を検討してください。 これらの拡張機能は、テスト ケース管理、探索的テスト、テスト実行追跡などの機能を提供することで、テスト機能を強化します。
- その他の機能: Azure DevOps には、特定のニーズに対応するさまざまな拡張機能と統合が用意されています。 Microsoft 以外のツールと統合する場合でも、セキュリティを強化する場合でも、デプロイ パイプラインを自動化する場合でも、さまざまなオプションがあります。
これらのサービスの一部には追加コストが発生する場合があるため、それに応じて要件と予算を評価することが不可欠です。 これらのコストは、関連するサブスクリプションの請求書に表示されます。 詳細については、「 課金の設定」を参照してください。 状況に関して具体的な質問がある場合は、DevOps パートナー、Microsoft リセラー、または Microsoft Developer Solutions Sales スペシャリストに問い合わせて、パーソナライズされたガイダンスを確認してください。
新しい組織を予約する
移行プロジェクトのタイムラインを考慮して、最終的な移行で目的の名前を使用できるように、組織の名前を早期に予約します。
たとえば、会社が Contoso で、 https://dev.azure.com/contosoなど、一致する名前の組織が必要な場合は、今すぐその名前の組織を作成します。 ただし、新しい Azure DevOps Services 組織にのみ移行できることに注意してください。
組織名を予約するには、次の手順を実行します。
- 初期予約:
-
https://dev.azure.com/contosoなど、目的の最終的な名前を持つ組織を作成します。 この手順では、移行期間中に他のユーザーが要求できないように、名前を予約します。 - 移行の準備ができるまで、この組織を維持します。
-
- 最終的な移行:
最終的な移行を開始する準備ができたら、
https://dev.azure.com/contoso-temporaryなどの一時的な組織に移行します。 既存の組織に移行することはできません。移行が成功したら、予約済みの組織 (
https://dev.azure.com/contoso) の名前をプレースホルダー名 (https://dev.azure.com/contoso-remove-laterなど) に変更します。 組織を削除するよりも名前を変更する方が望ましいです。削除すると、その名前が再び使用可能になるまで最大 1 時間かかることがあるためです。Note
別の組織の名前を変更する前に、名前の変更操作の後、少なくとも 1 時間待ちます。 詳細については、「 組織の名前を変更する」を参照してください。
移行された組織 (
https://dev.azure.com/contoso-temporary) の名前を目的の最終的な名前 (https://dev.azure.com/contoso) に変更します。必要に応じて、プレースホルダー組織 (
https://dev.azure.com/contoso-remove-later) を削除します。
このアプローチに従うことで、優先する組織名を引き続き使用できるようにしながら、スムーズに移行できます。