次の方法で共有

移行の概要

  • [アーティクル]

Azure DevOps Server から Azure DevOps Services への移行は、クラウドベースのコラボレーション、スケーラビリティ、および強化された機能を利用したい組織にとって不可欠なステップです。 この概要では、オンプレミスの Azure DevOps Server からクラウドベースの Azure DevOps Services に貴重なデータを転送するためのオプションについて説明します。

オンプレミスの Azure DevOps Server とクラウドベースの Azure DevOps Services のメインの違いについては、「Azure DevOps Services と Azure DevOps Server - Azure DevOps の比較」を参照してください。

選択した移行オプションに関係なく、ソース コードや作業項目など、最も重要な資産を決定することをお勧めします。 データサイズ、組織の複雑さについて考え、移行をスムーズかつ成功させるために、実際の移行前にテスト実行に十分な時間があることを確認する必要があります。

移行のアプローチ

Azure DevOps Services を採用するための具体的な動機に基づいて、移行に対する各アプローチの長所と短所を評価することが重要です。 適切な戦略は、独自のコンテキストと要件によって異なります。

[オプション] 推奨されるシナリオ 制限事項
1: 手動移行 小規模なプロジェクトまたは特定のデータ サブセットに使用します。 すべてのデータを完全に忠実に移行できるわけではないので、調整の対象となります。 この移行では XML テンプレートの移行がサポートされていないため、プロセス テンプレートを継承されたテンプレートとして再作成する必要があります。
2: Azure DevOps データ移行ツール さまざまなデータ型と複雑な構造を持つ中規模から大規模な移行に使用します。 変更なしで、1 つの Azure DevOps Server コレクションを 1 つの新しい Azure DevOps Services 組織にのみ "リフト アンド シフト" できます。 詳細については、「制限事項」セクションを 参照してください。
3: API ベースの移行 独自の移行要件または自動化のニーズを持つ組織に対して柔軟性とカスタマイズを提供します。 低忠実度、データ損失、ID の変更が発生する可能性があります。 詳細については、「制限事項」セクションを 参照してください。

オプション 1: 手動移行

たとえば、Microsoft の Azure DevOps チームが Azure DevOps Server から Azure DevOps Services への移行を選択した場合、Team Foundation バージョン管理 (TFVC) から Git への移行も決定しました。 移行には多くの計画が必要でしたが、移行時に、TFVC ソースの "ヒント" バージョンを使用して新しい Git リポジトリを作成し、Azure DevOps Server に履歴を残しました。 また、作業中の作業項目を移動し、すべての古いバグ、完了したユーザー ストーリーやタスクなどを残しました。

手動移行プロセス

  1. 移行する必要がある最も重要な資産 (通常はソース コード、作業項目、またはその両方) を特定します。 Azure DevOps Server の他の資産 (ビルド パイプライン、テスト 計画など) は、手動で移行するのが困難です。
  2. 移行に適した時間を特定します。
  3. ターゲット組織を準備します。 必要な組織とチーム プロジェクトを作成し、ユーザーをプロビジョニングします。
  4. データを移行します。
  5. ソースの Azure DevOps Server デプロイを読み取り専用にすることを検討してください。 これを行うには、次の方法があります。
    • プロジェクト レベルのアクセス許可を調整する: すべてのユーザーまたはグループのアクセス許可をプロジェクト レベルで読み取り専用に設定します。プロジェクトの設定でセキュリティ ロールを変更することで実行できます。
    • リポジトリの設定を変更する: リポジトリごとに、設定を変更して読み取り専用にすることができます。これには、読み取りアクションのみを許可するように各ユーザーまたはグループのアクセス許可を調整する必要があります。
    • 組み込みのセキュリティ グループを使用する: 組み込みのセキュリティ グループを使用して、アクセス許可をより効率的に管理します。 "閲覧者" などのグループにユーザーを割り当てて、読み取り専用アクセスを提供できます。
    • アクセス許可の変更のスクリプト作成: プロジェクトまたはリポジトリが多数ある場合は、スクリプト化が必要になることがあります。 Azure CLI DevOps 拡張機能を使用して、すべてのアクセス許可を一覧表示し、必要に応じて更新できます。
    • リポジトリ機能を無効にする: ビルドやプル要求など、リポジトリへのアクセスを無効にしますが、警告を表示してリポジトリを検出可能な状態に保ちます。 リポジトリのプロジェクト設定>リポジトリ>に移動し、[リポジトリを無効にする] の横にあるトグルを [オン] に移動します。

オプション 2: Azure DevOps 移行ツール

Azure DevOps データ移行ツールは、Azure DevOps Server から Azure DevOps Services へのデータの移行を容易にするために Microsoft によって提供される一連のユーティリティです。 これらのツールは、ソース コード、作業項目、テスト ケース、その他のプロジェクト関連データなど、さまざまな成果物を移行するための合理化されたアプローチを提供します。

移行プロセスを開始する前に、ツールで事前移行分析を実行してソース環境の準備状況を評価し、移行に影響を与える可能性のある潜在的な問題または依存関係を特定できます。 事前に潜在的な課題を計画して軽減できるように、準備状況を評価します。

移行ツールの制限事項

このツールを使用すると、1 つの Azure DevOps Server コレクションを 1 つの新しい Azure DevOps Service Organization に "リフト アンド シフト" できます。次の理由で変更はありません。

  • データの整合性と一貫性:
    • データを移行する場合、整合性と整合性メイン維持することが重要です。 移行中に変更を許可すると、データの破損や不整合につながる可能性があります。
    • このツールにより、転送プロセス中にデータがメインにそのまま残り、エラーのリスクが最小限に抑えられます。
  • ソース データの保持:
    • 移行ツールは、ターゲット環境でソース データを忠実にレプリケートすることを目的としています。
    • 変更によって元のデータが変更され、移行されたデータとソース データの間に不一致が発生する可能性があります。
  • 予測可能な動作:
    • 変更を制限することで、移行中の予測可能な動作が保証されます。
    • ユーザーは、予期しない変更を加えることなく、一貫性のある結果に依存できます。
  • 移行に重点を置き、変換ではありません。
    • 移行ツールの主な目的は、ある場所から別の場所にデータを移動することです。
    • データ変換 (値の変更など) は、通常、移行後に個別に処理されます。

移行前または移行後に不要なデータを消去できます。

移行ツールのプロセス

  1. Azure DevOps Server を最新の 2 つのリリースのいずれかに更新するなどの前提条件を満たす。
  2. Azure DevOps Services に移動する各コレクションを検証します。
  3. 移行ファイルを生成します。
  4. 移行の実行のためにすべてを準備します。
  5. テストの実行を実行します。
  6. 移行を実行します。
  7. ユーザーとデータが移行され、コレクションが期待どおりに機能していることを確認します。

オプション 3: API ベースの移行

何らかの理由でデータ移行ツールを使用できないが、オプション 2 よりも忠実度の高い移行が必要な場合は、パブリック API を使用してデータを移動するさまざまなツールから選択できます。

API ベースの移行の制限事項

API ベースの移行では、次の制限が発生します。

  • 忠実度の低い移行:
    • 制限事項: API ベースのツールでは、手動コピーよりも忠実度が高くなりますが、まだ忠実度は比較的低くなります。
    • 影響: これらのツールは忠実性を提供しますが、データのすべての側面を保持するわけではありません。
      • 例: TFVC 変更セットの元の日付 (Team Foundation バージョン管理) は保持されていません。
      • 多くの場合、作業項目の変更日も保持されません。
  • データ損失と ID の変更:
    • 制限事項: 移行中、ツールは作業項目の変更、TFVC 変更セット、パッケージ フィード、パイプライン成果物を再生します。
    • 影響: このプロセスは、データの損失、新しい ID の生成、作成、変更、および終了の日付の変更につながる可能性があります。
      • 例: 特定の日付に関連付けられている履歴コンテキストが失われ、レポートと追跡可能性に影響を与える可能性があります。

API ベースの移行プロセス

一般に、この方法は、手動コピーを超える追加の忠実性が重要な場合にのみお勧めします。 このアプローチを採用する場合は、1 つ以上のツールを使用した経験を持つコンサルタントを雇用し、最終的な移行の前にテスト移行を行うことを検討してください。

多くの組織では、作業のサブセットに対してのみ、非常に忠実な移行が必要です。 新しい作業は、Azure DevOps Services で直接開始される可能性があります。 忠実度の要件が厳しくない他の作業は、他のいずれかの方法を使用して移行できます。

サポートされているプロセス モデル

Azure DevOps Services では、次のプロセス モデルがサポートされています。

既定では、ホストされた XML は Azure DevOps Services でオフになっています。 移行中は、Azure DevOps Server でプロジェクトをカスタマイズした場合にのみ、Hosted XML プロセス モデルを有効にします。 プロジェクトが Hosted XML 上に配置されたら、移行後に継承された XML にアップグレードできます。

基本原則

Azure DevOps Services に移行するときは、次の主な原則と制限事項に留意してください。

  • Azure DevOps Services は英語のみです。Azure DevOps Server では複数の言語がサポートされていますが、現在、Azure DevOps Services では英語のみがサポートされています。 コレクションで英語以外の言語が使用されている場合、または過去に英語以外を使用していて、アップグレード中に言語を英語に変換した場合、データ移行ツールを使用することはできません。
  • 継承: アジャイル、スクラム、または CMMI プロセス テンプレートから作成され、カスタマイズされなかったプロジェクトは、移行後に継承プロセス モデル上にあります。
  • ホストされた XML: カスタマイズを含むプロジェクトでは、Hosted XML プロセス モデルが使用されます。
  • カスタマイズされたプロジェクトごとのプロセス: Azure DevOps Services ではプロジェクトでプロセスを共有できますが、データ移行ツールはカスタマイズされたチーム プロジェクトごとにホストされた XML プロセスを作成します。 たとえば、カスタマイズされたプロジェクトが 30 個ある場合は、30 個のホストされた XML プロセスを管理できます。 すべてのプロジェクトの Hosted XML プロセスをさらにカスタマイズする場合は、各 Hosted XML プロセスを個別に更新する必要があります。
  • プロセス検証: データ移行ツールのプロセス検証では、各プロジェクトのターゲット プロセス モデルが検出されます。 移行する前に、Hosted XML プロジェクトのプロセス検証エラーを修正する必要があります。 継承プロセス モデルを利用するために、いずれかのプロセス (アジャイル、スクラム、または CMMI) に合わせてプロジェクトのプロセスを更新することを検討できます。 プロセス検証の種類の詳細については、ドキュメントを参照してください。

リソース

次のステップ

Azure DevOps 移行ツールの概要