Skip to main content

企業への GitHub Actions の導入

エンタープライズで GitHub Actions をロールアウトする方法を計画できます。

企業向け GitHub Actions について

GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。GitHub Actions を使用すると、企業はテストやデプロイなどのソフトウェア開発ワークフローを自動化、カスタマイズ、実行できます。 詳細については、「企業向け GitHub Actions について」を参照してください。

セルフホスト ランナーで実行されているジョブの図

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

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

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

開発者に使用を許可するアクションを決定します。 まず、GitHub によって作成されたものではないサードパーティのアクションを許可するかどうかを決定します。 リポジトリ、組織、エンタープライズの各レベルで実行できるアクションを構成できます。また、GitHub によって作成されたアクションのみを許可するように選択できます。 サードパーティのアクションを許可する場合は、許可されるアクションを、検証済みの作成者によって作成されたもの、または特定のアクションのリストに制限できます。 詳細については、「リポジトリの GitHub Actions 設定の管理」、「Organization の GitHub Actions を無効化または制限する」、「Enterprise での GitHub Actions のポリシーの施行」を参照してください。

GitHub Actions ポリシーのスクリーンショット

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

監査ログのエントリ

セキュリティ

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

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

Enterprise 内で GitHub Actions の機能を使用しているユーザーに対して、適切なセキュリティ プラクティスを適用する計画を立てます。 これらのプラクティスの詳細については、「GitHub Actions のセキュリティ強化」を参照してください。

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

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

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

GitHub では、リポジトリまたは Organization レベルでシークレットを保存できます。 リポジトリ レベルのシークレットは、運用環境やテストなど、特定の環境のワークフローに限定できます。 詳細については、「暗号化されたシークレット」を参照してください。

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

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

GitHub 上のサード パーティのリポジトリからアクションを調達することには大きなリスクがあります。 サード パーティのアクションを許可する場合は、アクションを完全なコミット SHA にピン止めするなどのベスト プラクティスに従うことをチームに促す内部ガイドラインを作成する必要があります。 詳細については、「サード パーティ アクションを使用する」を参照してください。

インナーソーシング

企業が GitHub Actions の機能をインナーソース自動化にどのように使用できるかについて考えてみましょう。 インナーソーシングは、オープンソースの手法の利点を社内ソフトウェア開発サイクルに組み込む方法です。 詳細については、GitHub リソースの「インナーソース入門」を参照してください。

: 現在、再利用可能なワークフローは GitHub AE では使用できませんが、今後の更新で使用できるようになる予定です。

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

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

ワークフロー開発者がプライベート リポジトリに保存されているアクションを使用する場合は、最初にリポジトリをクローンするようにワークフローを構成する必要があります。 クローンする必要があるリポジトリの数を減らすには、よく使われるアクションを 1 つのリポジトリにグループ化することを検討してください。 詳細については、「カスタム アクションについて」を参照してください。

リソースの管理

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

ランナー

GitHub Actions ワークフローにはランナーが必要です。独自のランナーをホストするには、GitHub Actions セルフホスト ランナー アプリケーションをご自身のマシンにインストールする必要があります。 詳細については、「セルフホスト ランナーについて」を参照してください。

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

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

最後に、セルフホスト ランナーのセキュリティ強化を検討する必要があります。 詳細については、「GitHub Actions のセキュリティ強化」を参照してください。

Storage

成果物を使うと、ワークフロー内のジョブ間でデータを共有し、ワークフローが完了したときに、そのワークフローのデータを保存できるようになります。詳細については、「ワークフロー データを成果物として保存する」を参照してください。

使用状況の追跡

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

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

Enterprise でこれらの Webhook からデータ アーカイブ システムに情報を渡す方法を計画します。 GitHub から Webhook データを収集して処理するオープンソース ツールである、"CEDAR.GitHub.Collector" の使用を検討できます。 詳細については、Microsoft/CEDAR.GitHub.Collector リポジトリを参照してください。

また、チームがアーカイブ システムから必要なデータを取得できるようにする方法も計画する必要があります。