GitHub Actions への Enterprise の移行について
既存のシステ� から GitHub Actions に Enterprise を移行するために、移行を計画し、移行を完了し、既存のシステ� を廃止します。
このガイドでは、移行に関する具体的な考慮事� �について説明します。 GitHub Actions を Enterprise に導入する方法の詳細については、「Enterprise への GitHub Actions の導入」を参照してく� さい。
移行を計画する
Enterprise を GitHub Actions に移行する前に、移行するワークフローとその移行がチー� にどのように影響するかを特定し、移行を完了する方法とタイミングを計画する必要があります。
移行スペシャリストの活用
GitHub が移行に役立つ� �合があります。また、GitHub Professional Services を購入する利点が得られる� �合もあります。 詳細については、専任の担当者または GitHub の営業チー� にお問い合わせく� さい。
移行ターゲットの特定とインベントリ作成
GitHub Actions に移行する前に、既存のシステ� で Enterprise によって使用されているワークフローを完全に理解しておく必要があります。
まず、Enterprise 内の既存のビルドおよびリリース ワークフローのインベントリを作成し、どのワークフローがアクティブに使用されていて移行する必要があるかと、取り残されている可能性があるのはどれかに関する情� �を収集します。
次に、現在のプロバイダーと GitHub Actions の違いを確認します。 これは、各ワークフローの移行に関する問題や、Enterprise で機能の違いが生じる可能性がある� �所を評価するのに役立ちます。 詳細については、「GitHub Actions への移行」を参照してく� さい。
この情� �を使用すると、GitHub Actions への移行が可能で必要であるワークフローを判断できます。
移行によるチー� への影響を特定する
Enterprise 内で使用されているツールを変更すると、チー� の作業に影響します。 既存のシステ� から GitHub Actions にワークフローを移行すると、開発者の日常業務にどのような影響を与えるかを考える必要があります。
移行の影響を受けるプロセス、統合、サード パーティ製のツールを特定し、行う必要がある更新の計画を立てます。
移行がコンプライアンスに関する問題にどのように影響するかを考えます。 たとえば、既存の資� �情� �スキャンとセキュリティ分析ツールは GitHub Actions で動作しますか? それとも、新しいツールを使用する必要がありますか?
既存のシステ� のゲートとチェックを特定し、GitHub Actions で実装できることを確認します。
移行ツールの特定と検証
自動移行ツールを使用すると、Enterprise のワークフローを既存のシステ� の構文から、GitHub Actions で必要な構文に変換できます。 サードパーティ製のツールを特定するか、専任の担当者または GitHub の営業チー� に問い合わせて、GitHub が提供できるツールについて確認します。 たとえば、GitHub Actions Importer を使用して、サポートされているさまざまなサービスから CI パイプラインの計画、スコープ設定を行い、GitHub Actions に移行することができます。 詳しくは、「GitHub Actions Importer を使用した移行の自動化」をご覧く� さい。
移行を自動化するツールを特定した後、一部のテスト ワークフローでツールを実行し、結果が期待どおりであることを確認することで、ツールを検証します。
自動化されたツールではほとんどのワークフローを移行できるはずですが、少なくともごく一部は手動で書き換える必要がある可能性があります。 完了する必要がある手動の作業量を見積もります。
移行アプローチの決定
Enterprise に最適な移行アプローチを決定します。 小規模なチー� では、"完全な置き換え" アプローチを使用して、すべてのワークフローを一度に移行できる� �合があります。 大規模な Enterprise では、反復的なアプローチの方がより現実的な� �合があります。 移行全体を中央で管理することも、個々のチー� に独自のワークフローを移行してセルフ サービスを依� �することもできます。
アクティブな管理とセルフ サービスを組み合わせた反復的なアプローチをお勧めします。 内部チャンピオンとしての役割を果たせる早期導入者の小規模なグループから始めます。 ビジネスの幅を表すのに十分に包括的な一部のワークフローを特定します。 早期導入者と協力して、これらのワークフローを GitHub Actions に移行し、必要に応じて反復処理します。 これにより、他のチー� もワークフローを移行できることを確信できます。
その後、より大規模な Organization で GitHub Actions を使用できるようにします。 これらのチー� が独自のワークフローを GitHub Actions に移行するのに役立つリソースを提供し、既存のシステ� が廃止されるタイミングをチー� に知らせます。
最後に、特定の期間内に移行を完了するために古いシステ� をま� 使用しているチー� に知らせます。 他のチー� の成功を示し、移行が可能で望ましいことを伝えて安心させます。
移行スケジュールの定義
移行アプローチを決定した後、各チー� がワークフローを GitHub Actions に移行するタイミングを示すスケジュールを作成します。
まず、移行を完了する日付を決定します。 たとえば、現在のプロバイダーとの契約が終了するまでに移行を完了することを計画できます。
その後、チー� と協力して、チー� の目標を� 牲にすることなく、期限に間に合うスケジュールを作成します。 移行を求める個々のチー� のビジネスの周期とワークロードを確認します。 各チー� と連携して、配信スケジュールを理解し、チー� が配信能力に影響を与えない時間帯にワークフローを移行できるようにする計画を作成します。
GitHub Actions への移行
移行を開始する準備ができたら、上記で計画した自動ツールと手動書き換えを使用して、既存のワークフローを GitHub Actions に変換します。
また、おそらく成果物をアーカイブするスクリプト化されたプロセスを記述することで、既存のシステ� からの古いビルド成果物を維持することもできます。
既存のシステ� の廃止
移行が完了した後、既存のシステ� の廃止について考えることができます。
一定期間、両方のシステ� をサイド バイ サイドで実行しながら、GitHub Actions 構成が安定しており、開発者のエクスペリエンスを低下させていないことを確認できます。
最終的に、古いシステ� の使用を停止して切り離し、確実に Enterprise 内の誰も古いシステ� を再び有効にできないようにします。