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