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