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