GitHubの自動化には、通常、複数のコンポーネントが連携する必要があります。 ネイティブ コンポーネント GitHub 最も重要なものは次のとおりです。
- GitHub Actions ワークフロー。自動化ロジックを実行するためのランタイムを提供します。 すぐに使用できますが、それらは単一のリポジトリ内で動作しますが、リポジトリ全体またはリポジトリの外部で自動化するように拡張できます。
- GitHub Appsにはランタイムがありません。 代わりに、ID、アクセス許可、イベント配信が提供されるため、外部サービスやワークフローのどちらであっても、自動化を安全に認証して動作させることができます。
ほとんどのエンタープライズ 自動化では、 GitHub Apps と GitHub Actions が一緒に使用されます。 たとえば、 GitHub Actions で実行されているワークフローでは、 GitHub App を使用して、リポジトリまたは組織間でタスクを実行できる有効期間の短いトークンを取得できます。
このガイドでは、 GitHub Apps、外部オートメーション、および GitHub Actions が相互に補完する方法と、企業でそれぞれを使用するタイミングについて説明します。
GitHub Apps
GitHub Appは、リポジトリ、組織、または企業間での自動化に必要な ID、アクセス許可、Webhook イベントを提供します。 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 のアクセス許可に直接マップされます。
- ワークフローは、GitHub Appを使用して特定の
actions/create-github-app-tokenとして認証できます。 - GitHub Apps は、
repository_dispatchなどのイベントを使用してワークフローをトリガーできます。
外部オートメーションとサービス
外部オートメーションは、GitHub の外部で、お客様独自のインフラストラクチャ上で実行されます。 通常、これらのサービスは次のとおりです。
- GitHub App から Webhook イベントを受信する
- GitHub Appを使用して、有効期間の短いインストール トークンを要求する
- 実行時間の長いロジックまたはエンタープライズ間のロジックを実行する
- 外部ビジネス システムとの統合
たとえば、次のようになります。
- 組織全体の構成管理
- ポリシー適用サービス
- 複数リポジトリのコードまたはメタデータの同期
- コンプライアンス レポートの生成
- 組織間のイシューまたはプルリクエストの管理
これらのすべては、認証、ID、およびイベントの実行GitHub Apps、**** に依存します。
これらのコンポーネントの連携方法
ほとんどのエンタープライズ自動化では、堅牢でスケーラブルなワークフローを実現するために、 GitHub Apps、外部サービス、および GitHub Actions の組み合わせを使用します。
例えば次が挙げられます。
- エンタープライズ GitHub App は、新しいリポジトリの作成時に Webhook を受け取り、Webhook ペイロードを外部サービスが実行されているサーバーに送信します。
- 外部サービスは、必要な設定を標準化し、リソースをプロビジョニングします。
- このサービスは、リポジトリ内の GitHub Actions ワークフローをトリガーします。
- ワークフローは CI を実行し、テンプレートをデプロイするか、スキャンを構成します。
各コンポーネントは、異なる自動化レイヤーを処理します。
各種類の自動化を使用する場合
次のような場合はa GitHub App を使用します:
- 多くのリポジトリで動作する認証またはアクセス許可
- 外部システムとの統合
- Webhook 主導の自動化
- 有効期間が長いワークフローまたはエンタープライズ全体のワークフロー
- 監査可能性と ID の分離
必要に応じ 、外部オートメーションを 使用します。
- 継続的または外部で実行されるロジック GitHub
- 内部システムとの統合
必要な場合は、 GitHub Actions を使用します。
- CI/CD パイプライン
- リポジトリ スコープの自動化
- リポジトリ イベントに関連付けられている自動チェック
- GitHubのランナー インフラストラクチャを使用したロジックの実行
次の場合は、GitHub AppsとGitHub Actionsを一緒に使用します。
- ワークフローは、リポジトリの既定のアクセス許可を超えて動作する必要があります
- GitHub Appがワークフローをトリガーする必要がある
- 外部ロジックによってリポジトリ内の実行が調整される
- エンタープライズ全体のポリシーまたはワークフローには、ID とランタイムの両方が必要です