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 とサードパーティ システムの統合
- 多くのリポジトリ間での変更の調整
- エンタープライズ レベルのアクティビティを監視する有効期間の長いボットまたはサービスの実行
メモ
Enterprise-installed GitHub Apps では、すべての API エンドポイントを呼び出すことはできません。 「Enterprise に 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 を使用して、有効期間の短いインストール トークンを要求します
- 実行時間の長いロジックまたはエンタープライズ間のロジックを実行する
- 外部ビジネス システムとの統合
たとえば、次のようになります。
- 組織全体の構成管理
- ポリシー適用サービス
- 複数リポジトリのコードまたはメタデータの同期
- コンプライアンス レポートの生成
- 組織間のイシューまたはプルリクエストの管理
これらはすべて、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 とランタイムの両方が必要です
次のステップ
エンタープライズレベルのリソースにアクセスし、ワークフローを自動化できる GitHub Apps を作成するには、エンタープライズ アプリの作成 を参照してください。