企業向け GitHub Actions について
GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。GitHub Actions を使用すると、企業はテストやデプロイなどのソフトウェア開発ワークフローを自動化、カスタマイズ、実行できます。 詳しくは、「エンタープライズの GitHub Actions について」を参照してください。
大規模な企業に GitHub Actions を導入する前に、まず導入を計画し、企業が独自のニーズを最適にサポートするための GitHub Actions の使用方法について決定する必要があります。
ガバナンスとコンプライアンス
企業での GitHub Actions の使用を管理し、コンプライアンス義務を果たす計画を作成する必要があります。
開発者に使用を許可するアクションを決定します。 まず、インスタンスの外部からアクションにアクセスできるようにするかどうかを決定します。 Enterprise のユーザが GitHub.com または GitHub Marketplace からの他のアクションにアクセスする必要がある場合、いくつかの設定オプションがあります。詳細については、「Enterprise でのアクションの使用について」を参照してください。
次に、GitHub によって作成されたものではないサードパーティのアクションを許可するかどうかを決定します。 リポジトリ、組織、エンタープライズの各レベルで実行できるアクションを構成できます。また、GitHub によって作成されたアクションのみを許可するように選択できます。 サードパーティのアクションを許可する場合は、許可されるアクションを、検証済みの作成者によって作成されたもの、または特定のアクションのリストに制限できます。
詳しくは、「リポジトリの GitHub Actions の設定を管理する」、「Organization について GitHub Actions を無効化または制限する」、「エンタープライズで GitHub Actions のポリシーを適用する」をご覧ください。
OpenID Connect (OIDC) と再利用可能なワークフローを組み合わせて、リポジトリ、組織、エンタープライズの全体で一貫したデプロイを適用することを検討してください。 これを行うには、再利用可能なワークフローに基づいてクラウド ロールの信頼条件を定義します。 詳しくは、「再利用可能なワークフローでの OpenID Connect の使用」を参照してください。
Enterprise の監査ログで、GitHub Actions に関連したアクティビティに関する情報にアクセスできます。 ビジネス ニーズのために監査ログ データの保持期間より長くこの情報を保持する必要がある場合は、このデータをエクスポートして GitHub の外部に格納する方法を計画します。 詳しくは、「Enterprise の監査ログのストリーミング」と「ログの転送」をご覧ください。
セキュリティ
GitHub Actions のセキュリティ強化へのアプローチを計画する必要があります。
個々のワークフローとリポジトリのセキュリティ強化
Enterprise 内で GitHub Actions の機能を使用しているユーザーに対して、適切なセキュリティ プラクティスを適用する計画を立てます。 これらのプラクティスについて詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。
また、セキュリティについて既に評価済みのワークフローの再利用を推奨することもできます。 詳細については、「インナーソーシング」を参照してください。
シークレットとデプロイ リソースへのアクセスのセキュリティ保護
シークレットを保存する場所を計画する必要があります。 シークレットは GitHub に保存することをお勧めしますが、クラウド プロバイダーにシークレットを保存することも選択できます。
GitHub では、リポジトリまたは Organization レベルでシークレットを保存できます。 リポジトリ レベルのシークレットは、運用環境やテストなど、特定の環境のワークフローに限定できます。 詳しくは、「GitHub Actions でのシークレットの使用」を参照してください。
機密性の高い環境については、手動の承認による保護の追加を検討する必要があります。そうすることで、ワークフローは環境のシークレットにアクセスする前に承認を受けることが必要になります。 詳しくは、「デプロイに環境を使用する」を参照してください。
サード パーティのアクションのセキュリティに関する考慮事項
GitHub 上のサード パーティのリポジトリからアクションを調達することには大きなリスクがあります。 サード パーティのアクションを許可する場合は、アクションを完全なコミット SHA にピン止めするなどのベスト プラクティスに従うことをチームに促す内部ガイドラインを作成する必要があります。 詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。
インナーソーシング
企業が GitHub Actions の機能をインナーソース自動化にどのように使用できるかについて考えてみましょう。 インナーソーシングは、オープンソースの手法の利点を社内ソフトウェア開発サイクルに組み込む方法です。 詳細については、GitHub リソースの「インナーソース入門」を参照してください。
アクションを公開せずにエンタープライズ全体でアクションを共有するには、内部リポジトリにアクションを格納し、同じ組織またはエンタープライズ内の任意の組織が所有する他のリポジトリ内の GitHub Actions ワークフローへのアクセスを許可するようにリポジトリを構成します。 詳しくは、「アクションとワークフローを企業と共有する」を参照してください。
再利用可能なワークフローを使用すると、チームはあるワークフローを別のワークフローから呼び出すことができ、完全な重複を回避できます。 再利用可能なワークフローは、適切に設計され、既にテスト済みのワークフローをチームが使用できるようにすることで、ベスト プラクティスを促進します。 詳しくは、「ワークフローの再利用」を参照してください。
新しいワークフローを構築するための出発点を開発者に提供するには、スターター ワークフローを使用できます。 これにより、開発者の時間を節約できるだけでなく、企業全体の一貫性とベスト プラクティスが促進されます。 詳しくは、「Organization のスターター ワークフローを作成する」を参照してください。
ワークフロー開発者がプライベート リポジトリに保存されているアクションを使用する場合は、最初にリポジトリをクローンするようにワークフローを構成する必要があります。 クローンする必要があるリポジトリの数を減らすには、よく使われるアクションを 1 つのリポジトリにグループ化することを検討してください。 詳しくは、「カスタム アクションについて」を参照してください。
リソースの管理
GitHub Actions を使用するために必要なリソースの管理方法を計画する必要があります。
ハードウェア要件
パフォーマンスを低下させずに GitHub Actions からの負荷を処理するには、お使いの GitHub Enterprise Server インスタンスの CPU とメモリ リソースのアップグレードが必要な場合があります。 詳しくは、「GitHub Enterprise Server の GitHub Actions を使い始める」を参照してください。
ランナー
GitHub Actions ワークフローにはランナーが必要です。GitHub Actions セルフホステッド ランナー アプリケーションをご自身のマシンにインストールして、独自のランナーをホストする必要があります。 詳細については、「セルフホステッド ランナーの概要」を参照してください。
セルフホスト ランナーに物理マシン、仮想マシン、コンテナーのどれを使用するかを決定します。各ジョブに新しいイメージを使用するか、各ジョブの実行後にマシンをクリーンアップしない限り、物理マシンは以前のジョブの残りの部分を保持し、仮想マシンも同様になります。 コンテナーを選択した場合、ランナーの自動更新によってコンテナーがシャットダウンされ、ワークフローが失敗する可能性があることに注意する必要があります。 自動更新ができないようにするか、コンテナーを強制終了するコマンドをスキップすることで、これに対する解決策を考案する必要があります。
また、各ランナーを追加する場所も決定する必要があります。 セルフホスト ランナーを個々のリポジトリに追加することも、Organization 全体または Enterprise 全体でランナーを使用可能にすることもできます。 Organization レベルまたは Enterprise レベルでランナーを追加すると、ランナーの共有が可能になります。これにより、ランナー インフラストラクチャのサイズが小さくなる可能性があります。 ポリシーを使用して、Organization および Enterprise レベルのセルフホスト ランナーへのアクセスを制限できます。そのためには、特定のリポジトリまたは Organization にランナーのグループを割り当てます。 詳細については、「自己ホストランナーの追加」および「グループを使用してセルフホストランナーへのアクセスを管理する」を参照してください。
自動スケーリングを使って、使用可能なセルフホステッド ランナーの数を自動的に増減することを検討する必要があります。 詳しくは、「セルフホステッド ランナーによる自動スケーリング」を参照してください。
最後に、セルフホスト ランナーのセキュリティ強化を検討する必要があります。 詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。
Storage
成果物を使うと、ワークフロー内のジョブ間でデータを共有し、ワークフローが完了したときに、そのワークフローのデータを保存できるようになります。 詳しくは、「ワークフロー データを成果物として保存する」をご覧ください。
GitHub Actions には、依存関係をキャッシュしてワークフローの実行を高速化するために使用できるキャッシュ システムもあります。 詳しくは、「依存関係をキャッシュしてワークフローのスピードを上げる」を参照してください。
ワークフロー アーティファクト、キャッシュ、およびその他のワークフロー ログ用に外部 BLOB ストレージを構成する必要があります。 企業が使用する、サポートされているストレージ プロバイダーを決定します。 詳しくは、「GitHub Enterprise Server の GitHub Actions を使い始める」を参照してください。
GitHub Actions のポリシー設定を使用して、ワークフロー アーティファクトのストレージ、キャッシュ、ログ保持をカスタマイズできます。 詳しくは、「エンタープライズで GitHub Actions のポリシーを適用する」を参照してください。
使用状況の追跡
ワークフローの実行頻度、それらの実行の成功と失敗の数、どのリポジトリがどのワークフローを使用しているかなど、GitHub Actions の Enterprise の使用状況を追跡する計画を立てる必要があります。
Webhook を使用して、ワークフロー ジョブとワークフロー実行に関する情報をサブスクライブできます。 詳しくは、「webhook について」を参照してください。
Enterprise でこれらの Webhook からデータ アーカイブ システムに情報を渡す方法を計画します。 GitHub から Webhook データを収集して処理するオープンソース ツールである、"CEDAR.GitHub.Collector" の使用を検討できます。 詳細については、Microsoft/CEDAR.GitHub.Collector リポジトリを参照してください。
また、チームがアーカイブ システムから必要なデータを取得できるようにする方法も計画する必要があります。