企業の自動化

GitHub の自動化には、通常、複数のコンポーネントが連携する必要があります。最も重要な GitHub ネイティブコンポーネントは次のとおりです。

        **GitHub Actions ワークフロー**は、自動化ロジックを実行するためのランタイムを提供します。 すぐに使用できますが、それらは単一のリポジトリ内で動作しますが、リポジトリ全体またはリポジトリの外部で自動化するように拡張できます。

        **GitHub Apps** には、ランタイムがありません。 代わりに、ID、アクセス許可、イベント配信が提供されるため、外部サービスやワークフローのどちらであっても、自動化を安全に認証して動作させることができます。

大半のエンタープライズ自動化は、GitHub Apps と GitHub Actions を組み合わせて使用します。たとえば、GitHub Actions で実行されているワークフローでは、GitHub App を使用して、リポジトリまたは組織間でタスクを実行できる有効期間の短いトークンを取得できます。

このガイドでは、GitHub Apps、外部オートメーション、および GitHub Actions が互いにどのように補完しているか、またエンタープライズ内でどのような状況でそれぞれを使用するかについて説明します。

GitHub Apps

GitHub App は、リポジトリ、組織、企業間での自動化に必要な ID、アクセス許可、ウェブフックイベント を提供します。 GitHub Apps 自体はロジックを実行せず、他のシステムがロジックを実行できるようにします。

GitHub Apps は、エンタープライズ自動化をサポートします。

          最小限の特権の原則に従う**きめ細かなアクセス許可**

エンタープライズ、組織、またはリポジトリレベルでのスコープ付きインストール
セキュリティで保護されたアクセスのための有効期間の短いトークン
完全な監査可能性を持つ個別の ID

        **代理管理**はGitHub Appのマネージャーロールを通じて行われます。

エンタープライズアカウントによって所有されている場合の大規模な整合性

GitHub Apps を使用すると、何が有効になりますか?

GitHub Apps を使用すると、外部サービスやワークフローステップなど、 他の場所で記述する自動化を、付与したアクセス許可内の GitHub API に対して実行できます。例えば次が挙げられます。

Webhook イベントの受信と外部サービスの起動
ワークフローが既定のリポジトリスコープの外部で動作できるようにする
GitHub とサードパーティシステムの統合
多くのリポジトリ間での変更の調整
エンタープライズレベルのアクティビティを監視する有効期間の長いボットまたはサービスの実行

GitHub Actions

GitHub Actions は、 GitHub の組み込み ランタイム を提供して、リポジトリ内で自動化ロジックを実行します。ワークフローはセルフホステッドランナーで実行され、コード変更やリポジトリイベントに関連付けられているタスクに最適です。

GitHub Actions を使用して、次の場合に使用します。

CI/CD (ビルド、テスト、デプロイ)
プル要求のチェックと検証
リポジトリレベルのメンテナンスタスク
プッシュ、タグ、または問題の更新に応答するイベントドリブンワークフロー
cronを使ったスケジュールジョブ

GitHub Actions が GitHub Apps を使用する方法

GitHub Actions と GitHub Apps は深く接続されています。

ワークフローのアクセス許可は、 GitHub App アクセス許可に直接マップされます。
ワークフローは、actions/create-github-app-token を使用し、特定の GitHub App として認証を行うことができます。
GitHub Apps は、repository_dispatchなどのイベントを介してワークフローをトリガーできます。

外部オートメーションとサービス

外部オートメーションは、 GitHub の外部で、独自のインフラストラクチャで実行されます。通常、これらのサービスは次のとおりです。

GitHub App から webhook イベントを受信する
GitHub App を使用し、有効期間の短いインストールトークンを要求します
実行時間の長いロジックまたはエンタープライズ間のロジックを実行する
外部ビジネスシステムとの統合

たとえば、次のようになります。

組織全体の構成管理
ポリシー適用サービス
複数リポジトリのコードまたはメタデータの同期
コンプライアンスレポートの生成
組織間のイシューまたはプルリクエストの管理

これらはすべて、認証、ID、イベントに関して GitHub Apps に依存しています。ただし、実行に関してはこれに依存していません。

これらのコンポーネントの連携方法

ほとんどのエンタープライズ自動化では、GitHub Apps、外部サービス、および GitHub Actions の組み合わせを使用して、堅牢でスケーラブルなワークフローを実現します。

例えば次が挙げられます。

エンタープライズ GitHub App は、新しいリポジトリの作成時に Webhook を受信し、Webhook ペイロードを外部サービスが実行されているサーバーに送信します。
外部サービスは、必要な設定を標準化し、リソースをプロビジョニングします。
このサービスは、リポジトリ内で GitHub Actions ワークフローを開始します。
ワークフローは CI を実行し、テンプレートをデプロイするか、スキャンを構成します。

各コンポーネントは、異なる自動化レイヤーを処理します。

各種類の自動化を使用する場合

必要な場合は、GitHub App を使用します。

多くのリポジトリで動作する認証またはアクセス許可
外部システムとの統合
Webhook 主導の自動化
有効期間が長いワークフローまたはエンタープライズ全体のワークフロー
監査可能性と ID の分離

必要に応じ 、外部オートメーションを 使用します。

GitHub の外部で継続的に実行されるロジック
内部システムとの統合

必要な場合は、GitHub Actions を使用します。

CI/CD パイプライン
リポジトリスコープの自動化
リポジトリイベントに関連付けられている自動チェック
GitHubのランナーインフラストラクチャを使用したロジックの実行

次の場合は、 GitHub Apps と GitHub Actions を一緒に 使用します。

ワークフローは、リポジトリの既定のアクセス許可を超えて動作する必要があります
GitHub App は、ワークフローをトリガーする必要があります
外部ロジックによってリポジトリ内の実行が調整される
エンタープライズ全体のポリシーまたはワークフローには、ID とランタイムの両方が必要です

次のステップ

          [AUTOTITLE](/admin/managing-your-enterprise-account/creating-github-apps-for-your-enterprise) で、エンタープライズ レベルの GitHub Apps を設計および管理する方法について説明します。

この記事で