企業向けGitHub Actionsの導入

企業向け GitHub Actions について

          GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。
          GitHub Actionsを使用すると、企業はテストやデプロイなどのソフトウェア開発ワークフローを自動化、カスタマイズ、実行できます。 詳しくは、「[AUTOTITLE](/admin/github-actions/getting-started-with-github-actions-for-your-enterprise/about-github-actions-for-enterprises)」をご覧ください。

大規模な企業に GitHub Actions を導入する前に、まず導入を計画し、企業が独自のニーズを最適にサポートするために GitHub Actions をどのように使用するかを決定する必要があります。

ガバナンスとコンプライアンス

企業の GitHub Actions の使用を管理し、コンプライアンスの義務を満たす計画を作成する必要があります。

開発者が使用決定します。まず、インスタンスの外部からアクションへのアクセスを有効にするかどうかを決定します。 Enterprise のユーザが GitHub.com または GitHub Marketplace からの他のアクションにアクセスする必要がある場合、いくつかの設定オプションがあります。詳細については、 AUTOTITLE を参照してください。

次に、、および再利用可能なワークフローGitHubを許可するかどうかを決定します。リポジトリ、組織、およびエンタープライズレベルで実行できるアクションを構成でき、 GitHubによって作成されたアクションのみを許可するように選択できます。サードパーティのアクションを許可する場合は、許可されたアクションを、検証済みの作成者によって作成されたもの、または特定のアクション。

詳細については、「リポジトリのGitHub Actions設定の管理」、「組織のGitHub Actionsの無効化または制限」、「企業でGitHub Actionsのポリシーを適用する」を参照してください。

再利用可能なワークフローを OpenID Connect (OIDC) と組み合わせて、リポジトリ、Organization、または Enterprise 全体で一貫したデプロイを実施することを検討します。これを行うには、再利用可能なワークフローに基づいてクラウドロールの信頼条件を定義します。詳しくは、「再利用可能なワークフローでの OpenID Connect の使用」をご覧ください。

企業の監査ログの GitHub Actions に関連するアクティビティに関する情報にアクセスできます。ビジネスニーズで監査ログデータが保持されるよりも長くこの情報を保持する必要がある場合は、 GitHubの外部でこのデータをエクスポートして格納する方法を計画します。詳細については、「」を参照してください。企業の監査ログのストリーミングとログの転送。

          GitHub Actions CI/CD パイプラインの設定にアクセスするためのカスタム組織ロールを管理することで、最小限の特権の原則を実践できます。 カスタム組織の役割の詳細については、「 [AUTOTITLE](/organizations/managing-peoples-access-to-your-organization-with-roles/about-custom-organization-roles)」を参照してください。

セキュリティ

          GitHub Actionsのセキュリティ強化へのアプローチを計画する必要があります。

個々のワークフローとリポジトリのセキュリティ強化

企業内で GitHub Actions 機能を使用するユーザーに適切なセキュリティプラクティスを適用する計画を立てる。これらのプラクティスについて詳しくは、「セキュリティで保護された使用に関するリファレンス」を参照してください。

また、セキュリティについて既に評価済みのワークフローの再利用を推奨することもできます。詳細については、「インナーソーシング」を参照してください。

シークレットとデプロイリソースへのアクセスのセキュリティ保護

シークレットを保存する場所を計画する必要があります。シークレットは GitHubに格納することをお勧めしますが、クラウドプロバイダーにシークレットを格納することもできます。

          GitHubでは、リポジトリまたは組織レベルでシークレットを格納できます。 リポジトリ レベルのシークレットは、運用環境やテストなど、特定の環境のワークフローに限定できます。 詳しくは、「[AUTOTITLE](/actions/security-guides/encrypted-secrets)」をご覧ください。

機密性の高い環境については、手動の承認による保護の追加を検討する必要があります。そうすることで、ワークフローは環境のシークレットにアクセスする前に承認を受けることが必要になります。詳しくは、「デプロイメント用の環境管理」をご覧ください。

サードパーティのアクションのセキュリティに関する考慮事項

          GitHub上のサードパーティ リポジトリからアクションをソーシングする場合、重大なリスクがあります。 サード パーティのアクションを許可する場合は、アクションを完全なコミット SHA にピン止めするなどのベスト プラクティスに従うことをチームに促す内部ガイドラインを作成する必要があります。 詳しくは、「[AUTOTITLE](/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)」をご覧ください。

インナーソーシング

企業が GitHub Actions の機能を使用して内部ソースの自動化を行う方法について考えてみましょう。 Innersourcing は、open source手法の利点を内部ソフトウェア開発サイクルに組み込む方法です。詳細については、「リソースの GitHub」を参照してください。

アクションを公開せずにエンタープライズ全体でアクションを共有するには、内部リポジトリにアクションを格納し、同じ組織またはエンタープライズ内の任意の組織が所有する他のリポジトリ内の GitHub Actions ワークフローへのアクセスを許可するようにリポジトリを構成します。詳しくは、「アクションとワークフローを企業と共有する」をご覧ください。

再利用可能なワークフローを使用すると、チームはあるワークフローを別のワークフローから呼び出すことができ、完全な重複を回避できます。再利用可能なワークフローは、適切に設計され、既にテスト済みのワークフローをチームが使用できるようにすることで、ベストプラクティスを促進します。詳しくは、「ワークフローを再利用する」をご覧ください。

新しいワークフローを構築するための出発点を開発者に提供するには、ワークフローテンプレートを使用できます。これにより、開発者の時間を節約できるだけでなく、企業全体の一貫性とベストプラクティスが促進されます。詳しくは、「組織のワークフローテンプレートを作成する」をご覧ください。

リソースの管理

          GitHub Actionsを使用するために必要なリソースを管理する方法を計画する必要があります。

ハードウェア要件

パフォーマンスの低下を引き起こさずに、お使いの GitHub Enterprise Server インスタンスからの負荷を処理するために、GitHub Actionsの CPU リソースとメモリリソースをアップグレードする必要がある場合があります。詳しくは、「GitHub Enterprise Server で GitHub Actions を開始する方法」をご覧ください。

ランナー

          GitHub Actions ワークフローにはランナーが必要です。 
          GitHub Actionsセルフホステッド ランナー アプリケーションを自分のコンピューターにインストールして、独自のランナーをホストする必要があります。 詳細については、 [AUTOTITLE を](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)参照してください。

          セルフホステッド ランナーに物理マシン、仮想マシン、コンテナーのどちらを使用するかを決定します。 ジョブごとに新しいイメージを使うか、各ジョブの実行後にマシンをクリーンアップしない限り、物理マシンには以前のジョブの残存物が残りますが、仮想マシンも同様です。 コンテナーを選択した場合、ランナーの自動更新によってコンテナーがシャットダウンされ、ワークフローが失敗する可能性があることに注意する必要があります。 自動更新ができないようにするか、コンテナーを強制終了するコマンドをスキップすることで、これに対する解決策を考案する必要があります。

また、各ランナーを追加する場所も決定する必要があります。セルフホステッドランナーを個々のリポジトリに追加することも、Organization 全体または Enterprise 全体でランナーを使用可能にすることもできます。 Organization レベルまたは Enterprise レベルでランナーを追加すると、ランナーの共有が可能になります。これにより、ランナーインフラストラクチャのサイズが小さくなる可能性があります。ポリシーを使用して、Organization および Enterprise レベルのセルフホステッドランナーへのアクセスを制限できます。そのためには、特定のリポジトリまたは Organization にランナーのグループを割り当てます。詳細については、「自己ホストランナーの追加」および「グループを使用してセルフホストランナーへのアクセスを管理する」を参照してください。また、ポリシーを使用して、ユーザーがリポジトリレベルのセルフホステッドランナーを使用するのを禁止することもできます。詳しくは、「企業でGitHub Actionsのポリシーを適用する」をご覧ください。

自動スケールを使って、使用可能なセルフホステッドランナーの数を自動的に増減することを検討する必要があります。詳しくは、「セルフホステッドランナーリファレンス」をご覧ください。

最後に、セルフホステッドランナーのセキュリティ強化を検討する必要があります。詳しくは、「セキュリティで保護された使用に関するリファレンス」をご覧ください。

Storage

          成果物を使うと、ワークフロー内のジョブ間でデータを共有し、ワークフローが完了したときに、そのワークフローのデータを保存できるようになります。 詳細については、 [AUTOTITLE を](/actions/using-workflows/storing-workflow-data-as-artifacts)参照してください。

          GitHub Actions には、依存関係をキャッシュしてワークフローの実行を高速化するために使用できるキャッシュ システムもあります。 詳しくは、「[AUTOTITLE](/actions/using-workflows/caching-dependencies-to-speed-up-workflows)」をご覧ください。

ワークフロー成果物、キャッシュ、およびその他のワークフローログ用に外部 BLOB ストレージを構成する必要があります。企業が使用する、サポートされているストレージプロバイダーを決定します。詳しくは、「GitHub Enterprise Server で GitHub Actions を開始する方法」をご覧ください。

          GitHub Actionsのポリシー設定を使用して、ワークフロー成果物、キャッシュ、およびログ保持のストレージをカスタマイズできます。 詳しくは、「[AUTOTITLE](/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise)」をご覧ください。

使用状況の追跡

ワークフローの実行頻度、それらの実行の成功と失敗の数、どのリポジトリがどのワークフローを使用しているかなど、企業の GitHub Actionsの使用状況を追跡する計画を立てる必要があります。

Webhook を使用して、ワークフロージョブとワークフロー実行に関する情報をサブスクライブできます。詳しくは、「webhook について」をご覧ください。

企業がこれらの Webhook からデータアーカイブシステムに情報を渡す方法を計画し、チームがアーカイブシステムから必要なデータを取得できるようにする方法を計画します。

この記事で