1. Enterprise Live Migrations について学習する

Azure DevOps サービス

Enterprise Live Migrations (ELM) は、データ所在地に対応した GitHub Enterprise Cloud への Azure DevOps リポジトリの移行を、中断を最小限に抑えながら支援します。 ELM はソース リポジトリとターゲット リポジトリを継続的に同期するため、カットオーバーの準備ができるまでチームは Azure DevOps Services で作業を続けることができます。 完全にGitHubにカットオーバーするか、チームがAzure BoardsとAzure Pipelinesを引き続き使用している間にソース コードがGitHubに移行されるハイブリッド モデルを使用する、という 2 つの移行パスがあります。

ELM は、Azure DevOps CLI と Azure DevOps ポータルの 2 つのエクスペリエンスで利用できます。 コマンド ラインから移行をスクリプトまたは実行する場合は、CLI を使用します。 リポジトリの選択、移行の開始、進行状況の追跡に関するガイド付きエクスペリエンスが必要な場合は、ポータルを使用します。

コア機能

ELM には、次のコア機能が用意されています。

• 継続的同期:ELM は、増分同期と差分追跡を使用して、Azure DevOpsからGitHubへの変更を同期するため、チームはカットオーバーまでAzure DevOps作業を続けることができます。 カットオーバー時に短い読み取り専用ウィンドウを計画します。通常、ほとんどのリポジトリでは 30 分以内です。
• 複数リポジトリの移行: ELM では、複数のリポジトリの移行がサポートされ、最大 20 個の同時移行ジョブがサポートされます。 CLI で、各リポジトリの移行コマンドを一度に 1 つずつ実行します。 UI では、最大 20 個のリポジトリを選択して一緒に移行できます。
• エンドツーエンドの移行ワークフロー: ELM は、初期化、同期、カットオーバー、検証、完了を通じてリポジトリの状態を追跡します。 このモデルでは、移行の進行状況を可視化し、トラブルシューティングをサポートします。
• 顧客がスケジュールしたカットオーバー:レコードのシステムをAzure DevOpsからGitHubに切り替えるには、カットオーバー時間を選択してスケジュールします。
• 移行後のセットアップが簡単になりました。ELM は、Azure Boards接続を設定し、移行されたGitHub リポジトリを指すAzure Pipelinesを再配線することで、カットオーバー後の手動作業を削減するのに役立ちます。 これにより、チームは、ソース コードのGitHubから作業しながら、計画とパイプラインにAzure DevOpsを引き続き使用し続け、ハンドオフの作業が少なくなり、フォローアップ タスクも少なくなります。

移行データ フロー

ELM は、暗号化されたチャネル経由でソースから GitHub Enterprise Cloud にリポジトリ データを転送します。 リポジトリの内容、履歴、メタデータ、アクセス許可を移行した後、増分同期を使用して、最初の転送後にのみ変更をコピーします。 ELM は、顧客リポジトリのコンテンツを移行プロセスの外部に格納しません。

セキュリティとデータの処理

ELM は、リポジトリのコンテンツが管理下に留まります。Microsoftは、移行を実行するために必要な最小限の運用データのみを保持するように設計されています。

転送中のデータ

Azure DevOps、セルフホステッド Linux エージェント、および GitHub Enterprise Cloud 間のすべての通信では、TLS で暗号化された HTTPS が使用されます。 リポジトリの内容は、暗号化された Git プロトコル経由で転送されます。 ELM は、アクティブな移行プロセスの外部に顧客リポジトリのコンテンツを格納しません。

PAT処理

ELM には、それぞれ異なる目的で使用される 2 つのGitHub個人用アクセス トークン (AT) が必要です。 両方をシークレットとして扱い、「前提条件」に記載されているスコープのみを付与します。 両方の PAT に短い有効期限を設定し、移行の完了後にローテーションまたは取り消します。 露出が疑われる場合は、すぐに PAT を取り消します。 移行オペレーターと必要な管理者へのサービス接続を表示または編集できるユーザーを制限します。

• サービス接続 PAT:GitHub Enterprise 管理者はこの PAT を作成し、それを使用してターゲット GitHub組織のAzure DevOps サービス接続を作成します。 この PAT は、サービス接続にのみ格納します。 ソース管理にコミットしたり、チャットで共有したり、ログに貼り付けたりしないでください。
• 個人用移行 PAT:移行を実行するユーザーは、この PAT を作成し、それを使用して、移行中にGitHubに対する認証を行います。

Microsoftが保持するもの

ELM には、リポジトリ ID、移行状態、検証結果、エラー メッセージ、監査イベントなど、移行に関する操作メタデータのみが格納されます。 ELM では、移行が完了した後も、リポジトリの内容、コミット データ、PAT は保持されません。

Audit

ELM は、移行ライフサイクル イベントをAzure DevOps監査ログに書き込みます。そのため、エンタープライズ管理者は、移行を開始、一時停止、再開、スケジュールされたカットオーバー、または破棄したユーザーを確認できます。 監査ログを使用してコンプライアンス レビューをサポートし、問題を調査する必要がある場合は移行タイムラインを再構築します。

監査イベントを表示するには、 組織の設定>監査 に移動し、 Enterprise Live Migrations 領域でフィルター処理します。

ELM のスコープ

ELM が自動化するもの

• 移行前チェックを実行します。
• ブランチ、変更履歴、タグを含む Git コードをGitHubに同期します。
• タイトル、説明、コメント、ユーザー履歴など、プル要求を同期します。
• ターゲット GitHub リポジトリを作成します。
• ブランチ ポリシーをGitHubブランチ ルールセットに移行します。
• 新しいGitHub リポジトリを参照するAzure Pipelinesを再配線します。
• ボード接続を作成します。
• Azure DevOps から GitHub に切り替えます。

手動で行うこと

• 移行前にAzure DevOpsリポジトリをクリーンアップします (大きなファイル、10,000 以上のファイル、長い ref 名を含むプル要求)。
• ターゲット GitHub組織を作成します。
• 移行後のリポジトリの状態 (ブランチ、タグ、履歴、プル要求) を確認します。
• 移行されたブランチ ルールセットを確認して調整します。
• スクリプト、パイプライン、ツールでハードコーディングされた Azure DevOps リポジトリ URL を更新します。
• GitHubでチームとユーザーのアクセスを設定します。
• 作業項目、Wiki、パイプライン、およびその他のリポジトリ以外のデータを移行または使用停止します。

ELM が移行する内容

移行されたデータ

ELM は現在、Azure DevOps Services から GitHub Enterprise Cloud に次のリポジトリ データをデータ所在地と共に移行しています。

• 完全なコミット履歴を含む Git ソース
• ブランチとタグ
• GitHub のブランチ ルールセットとして移行されたブランチ ポリシー
• タイトル、説明、ソースブランチとターゲットブランチ、コメントを含むプル要求メタデータ
• pull request のユーザー履歴

移行されていないデータ

ELM では、次のデータは移行されません。

• 作業項目
• パイプライン定義
• リリース
• ウィキス
• テスト計画とテスト結果
• Azure Artifacts
• Git LFS オブジェクト（今後対応予定）

ELM は、アクティブなプル要求とマージされたプル要求と、使用可能なブランチ履歴を含むプル要求を移行します。 ブランチが削除された放棄済みのプル リクエストは移行されません。

ELM でのパイプラインの使用方法とコストに対する期待

ELM は、セルフホステッド Linux エージェントを使用してAzure Pipelinesで実行されます。 移行中、ELM は次の 2 種類のジョブを使用します。

• 初期検証 では、リポジトリを移行する準備ができていることを確認します。 このジョブは 1 回実行されます。
• Sync はリポジトリをGitHubにコピーし、カットオーバーまで変更を同期し続けます。

セルフホステッド Linux エージェントは、移行期間中はオンラインのままで使用できる必要があります。

ELM でのエージェント プールの使用方法

ELM は、既存のパイプラインへの影響を最小限に抑えます。 プール内のエージェントの数に関係なく、一度に使用するエージェントは 1 つだけです。 各リポジトリについて、ELM は一度に 1 つのジョブをキューに入れ、ジョブを並列で実行せず、通常は 30 ~ 60 分待ってから次のジョブをキューに入れ、他のパイプライン作業を続行できます。

実際には、ELM は他のパイプライン ジョブと同様に動作し、現在のビルドと容量を共有します。 プール全体を占有したり、無関係な作業を妨げたりするべきではありません。

コストに対して何を期待するか

ELM 自体は自由に使用できます。 組織に含まれている並列ジョブの割り当てを超えた場合に発生する可能性があるコストは、Azure Pipelines のキャパシティに対するもののみです。

各 ELM ジョブは最大 1 時間実行できますが、Azure Pipelines課金は、使用されたエージェント数や分数ではなく、並列ジョブ容量に基づきます。 ELM はそれ自体を 1 つの同時実行ジョブに制限するため、多くのお客様は、追加コストなしで既存の容量内で移行を実行できます。 含まれる容量を超えた場合は、追加の並列ジョブを購入する必要が生じることがあります。 Azure Pipelinesにはプライベート プロジェクトの無料分も含まれているため、追加コストは通常、Free レベルが使い果たされた後にのみ適用されます。

移行のワークフロー

大まかに言えば、ELM の移行は次の手順に従います。 各手順は、詳細な手順にリンクしています。

1. Enterprise Live Migrations について説明します。 この概要を確認して、ELM の機能、移行内容、および移行計画にどのように適合するかを理解します。 チームが開発ワークフローを完全にGitHubに移行するか、ハイブリッド モデルでAzure DevOpsとGitHubを引き続き使用するかを決定します。 ハイブリッド モデルを選択した場合、ELM は移行後のセットアップを減らすのに役立ちます。移行されたGitHub リポジトリにAzure Pipelinesを再配線し、Azure Boards接続を作成します。
2. 前提条件を満たす。 アクセス、ツール、認証を確認し、移行コマンドを実行するために必要な ID を収集します。 詳細については、「 前提条件の完了」を参照してください。
3. 移行を開始します。 Azure DevOpsで認証し、既定値を設定し、ELM CLI を使用して初期同期を開始します。 詳細については、「 移行の開始」を参照してください。
4. 移行を監視する。 初期同期と、それに続く増分同期を監視します。 詳細については、「 移行の監視」を参照してください。
5. GitHub へ切り替える。 準備ができ次第、できるだけ早くカットオーバーをスケジュールしてください。 完全な移行を開始してから 21 日以内 (初期同期が開始されたとき) にカットオーバーを完了する必要があります。 詳細については、「Cutover to GitHub」を参照してください。
6. 移行後のタスクを完了します。 移行が完了した後にすべてが機能することを確認します。 詳細については、「 移行後のタスクの完了」を参照してください。

移行前の検証チェック

次の表に、検証中にチェックされた現在のツールの制限と、それらが対処されていない場合の動作を示します。

主要な役割と責任

次のステップ

関連するコンテンツ

• 前提条件を満たす
• ELM CLI リファレンス