GitHub Actions への移行の計画
このガイドでは、GitHub Actions への移行を計画する際に考慮すべき点の概要を示します。技術的必須要件を特定する方法、移行するプロジェクトやリポジトリを決定する方法、ベストプラクティスを統合する方法、およびエンジニアリング チームの組織としてのカルチャーを考慮する方法について説明します。途中で Salesforce から、同社が短いタイムラインで移行を成功させた方法について話を聞きます。
このガイドの学習内容
移行に不可欠な技術要件と製品要件を特定する方法
移行するプロジェクトやリポジトリを理解することの重要性
テストの最適化や再利用可能なワークフローの作成など、移行中にベストプラクティスを統合するための戦略
移行を成功へと導くエンジニアリング チームの組織的および文化的構造の役割
要件を収集する
初期段階で着手: 特定の技術要件を明確にします。次の CI/CD ツールに Mac ランナーと M1 ランナーが必要な場合でも、再利用可能なリソースと使いやすいテンプレートの確保に重点を置く場合でも、これらのニーズを事前に明確にする必要があります。さらに、ガバナンスと Enterprise の制御がチェックリストに含まれている場合は、最初の段階でそれを明確にしておきます。これらの優先順位を明示的に示すことができれば、移行評価のガイドとなるだけでなく、新しいツールを組織の目標に沿ったものにできます。計画に対する正しい考え方、つまり必要なものを正確に把握することが、移行を成功させるためのロードマップとなります。
何を移行するか
移行プロセスを開始する前に、どのプロジェクトを移行するのかを正確に特定します。未着手のプロジェクトのみを対象としますか？ それとも、既存のモノリシック システムも移行しますか？ 社内ツールに新しい場所が必要ですか？ 移行の具体的な領域を知ることにより、移行後の道筋が決まります。最初は 1 つのリポジトリ グループから始めて、後で他のグループに広げることもできます。この定義済みシーケンスによって、移行作業が簡素化されるだけでなく、全体的なプロセスの管理も容易になります。
Salesforce では、わずか 60 日以内に CI/CD パイプライン全体を新しいシステムに移行しなければなりませんでした。構成や設定を簡単に移行できる、GitHub Actions Importer ツールはこの移行に不可欠でした。 このセルフサービス機能の大きなメリットは、より多くのチーム メンバーが参加でき、全員に確かな出発点を与えることができたことでした。IssueOps も画期的でした。インシデントの処理方法を合理化でき、シームレスな調整が可能になりました。これらの要素が全て組み合わさったことにより、パイプラインの整合性とパフォーマンスを維持しながら、期限を確実に守ることができました。
改善領域を特定する
移行は、組織にベスト プラクティスを浸透させる絶好の機会です。古い YAML ファイルまたは Groovy ファイルから新しいGitHub Actions に移行し、その過程で更新していくときが、戦略を再考するのに最適なタイミングです。たとえば、これまで一貫して 1 時間以上かかっていたテストがある場合、新しい環境では 30 分以内に終わるようにすることを目指します。再利用可能なワークフローに合理化できる冗長なプラクティスを探します。この考え方は、移行の準備をするうえで非常に重要です。単に変更と転換を行うだけでなく、最適化と改善も行う必要があります。
エンジニアリング チームの組織的および文化的構造も、移行において重要な役割を果たします。ベスト プラクティスを簡単に採用できる「整備されたパス」の文化を浸透させたいなら、自由な開発環境とは大きく異なる方法で CI/CD ツールを設定する必要があります。お客様によっては、移行を機会として捉え、エンジニアリング チームにまったく新しい文化や考え方を取り入れることを選ぶ場合もあります。たとえば、再利用可能なワークフローを確立し、CI/CD 管理を一元化すれば、開発者が得意とする開発に集中できるようになります。
次の内容: シークレットと変数で CI/CD パイプライン の安全を確保する
移行を成功させるための準備方法を理解したところで、Organization レベルで極秘情報を管理する方法、ワークフローでの変数の役割を理解する方法、堅牢なクラウド認証のために OpenID Connect (OIDC) を実装する方法を見てみましょう。