{"meta":{"title":"GitHub Actionsを使用したデプロイ","intro":"GitHub Actions では、環境、コンカレンシー グループ、保護規則を使用してデプロイをきめ細かく制御できます。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/actions","title":"GitHub Actions"},{"href":"/ja/actions/how-tos","title":"方法"},{"href":"/ja/actions/how-tos/deploy","title":"デプロイ"},{"href":"/ja/actions/how-tos/deploy/configure-and-manage-deployments","title":"デプロイの構成と管理"},{"href":"/ja/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments","title":"デプロイを制御する"}],"documentType":"article"},"body":"# GitHub Actionsを使用したデプロイ\n\nGitHub Actions では、環境、コンカレンシー グループ、保護規則を使用してデプロイをきめ細かく制御できます。\n\n## 前提条件\n\nGitHub Actionsの構文を理解している必要があります。 詳しくは、「[ワークフローの書き込み](/ja/actions/how-tos/write-workflows)」をご覧ください。\n\n## デプロイのトリガー\n\nさまざまなイベントを使用して、デプロイ ワークフローをトリガーできます。 最も一般的なのは、`pull_request`、`push`、および `workflow_dispatch` です。\n\nたとえば、次のトリガーを持つワークフローは、次の場合、常に実行されます。\n\n* `main` ブランチへのプッシュがある。\n* `main` ブランチを対象とする pull request が開かれる、同期される、または再び開かれる。\n* 誰かが手動でトリガーする。\n\n```yaml\non:\n  push:\n    branches:\n      - main\n  pull_request:\n    branches:\n      - main\n  workflow_dispatch:\n```\n\n詳しくは、「[ワークフローをトリガーするイベント](/ja/actions/reference/workflows-and-actions/events-that-trigger-workflows)」をご覧ください。\n\n## 環境の使用\n\n環境は、一般的なデプロイ ターゲットを記述するために使用されます (例: `production`、`staging`、または `development`)。\nGitHub Actions ワークフローが環境にデプロイされると、その環境がリポジトリのメイン ページに表示されます。 環境を使って、ジョブを進めるために承認を必要とすること、ワークフローをトリガーできるブランチを制限すること、カスタム デプロイ保護規則でデプロイを制限すること、またはシークレットへのアクセスを制限することができます。 環境の作成の詳細については、「[デプロイメント用の環境管理](/ja/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)」を参照してください。\n\n保護ルールとシークレットを持つ環境を設定できます。 ワークフローのジョブが環境を参照すると、その環境の保護ルールをすべてパスするまではジョブは開始されません。 すべてのデプロイ保護規則をパスするまで、ジョブは環境で定義されているシークレットにアクセスできません。 詳しくは、この記事の「[カスタム デプロイ保護規則の使用](#using-custom-deployment-protection-rules)」をご覧ください。\n\n## コンカレンシーの使用\n\n並行処理により、同じ並行処理グループを使用する単一のジョブまたはワークフローのみが一度に実行されます。 並行処理を利用することで、ある環境において、同時に進行中のデプロイが最大 1 件、最大 1 件となるように設定できます。 コンカレンシーについて詳しくは、「[ワークフローとジョブの並行処理を制御する](/ja/actions/how-tos/write-workflows/choose-when-workflows-run/control-workflow-concurrency)」をご覧ください。\n\n## デプロイなしで環境を使用する\n\n既定では、ワークフロー ジョブが環境を参照する場合、 GitHub はデプロイを追跡するデプロイ オブジェクトを作成します。\n`deployment`を環境構成で`false`に設定することで、デプロイの作成をオプトアウトできます。 有効な値は `true` (既定値) と `false`です。\n`deployment: ${{ github.ref_name == 'main' }}`などの式を使用することもできます。\n\n```yaml\njobs:\n  test:\n    runs-on: ubuntu-latest\n    environment:\n      name: staging\n      deployment: false\n    steps:\n      - name: run tests\n        env:\n          API_KEY: ${{ secrets.API_KEY }}\n        run: echo \"Running tests with staging secrets\"\n```\n\n`deployment`が`false`に設定されている場合:\n\n* ジョブには、環境シークレットと変数へのフル アクセス権があります。\n* GitHubデプロイ オブジェクトは作成されません。環境のデプロイ履歴は更新されません。\n* 待機タイマー保護規則は引き続き適用されます。ジョブは、構成された期間、待機します。\n* 必須のレビュー担当者は引き続き適用されます。レビュー担当者は、ジョブを実行する前に承認する必要があります。\n\nこれは、次の環境を使用する場合に便利です。\n\n* **シークレットの整理** - デプロイ レコードを作成せずに、環境名の下に関連するシークレットをグループ化します。\n* **アクセス制御** - 環境ブランチ ポリシーを使用して特定のシークレットを使用できるブランチを、デプロイの追跡なしで制限します。\n* **CI およびテスト ジョブ** - デプロイ履歴にノイズを追加することなく、その構成の環境を参照します。\n\n### 保護規則とのやり取り\n\n`deployment` プロパティは、適用する保護規則を制御します。\n\n\\| 保護ルール |\n`deployment: true` (既定値) | `deployment: false` |\n\\|----------------|------------------------------|---------------------|\n\\| **なし** | デプロイが作成され、ジョブが実行される | デプロイなし、ジョブの実行 |\n\\| **待機タイマー** | 待機タイマーの適用 | 待機タイマーは引き続き適用されます |\n\\| **必須の校閲者** | レビュー担当者が承認する必要がある | レビュー担当者が承認する必要がある |\n\\| **カスタム展開保護規則アプリ** | 送信されたアプリのWebhookを承認する必要があります。 |\n**ジョブがエラーで失敗する** |\n\nカスタム展開保護規則 (GitHub Apps) を機能させるためには、デプロイ オブジェクトが必要です。 カスタム展開保護規則を持つ環境で `deployment: false` を設定すると、環境の保護規則が `deployment: false`と互換性がないことを説明する注釈またはエラー メッセージが表示され、ジョブはすぐに失敗します。 ワークフローから `deployment: false` を削除するか、環境からカスタム展開保護規則を削除します。\n\n`concurrency`と`environment`は接続されていないことに注意してください。 コンカレンシー値には任意の文字列を指定できます。環境名である必要はありません。 さらに、別のワークフローが同じ環境を使用していてもコンカレンシーを指定していない場合、そのワークフローはコンカレンシー ルールの対象になりません。\n\nたとえば、次のワークフローを実行すると、`pending` コンカレンシー グループを使用するジョブまたはワークフローが進行中の場合、`production` 状態で一時停止します。 また、`production` コンカレンシー グループを使用し、状態 `pending` を持つジョブまたはワークフローもキャンセルします。 つまり、`production` コンカレンシー グループを使用するジョブまたはワークフローは、最大で 1 つ実行され、1 つ保留中になります。\n\n```yaml\nname: Deployment\n\nconcurrency: production\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nジョブ レベルでコンカレンシーを指定することもできます。 これにより、同時実行ジョブが `pending`でも、ワークフロー内の他のジョブを続行できます。\n\n```yaml\nname: Deployment\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    concurrency: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nまた、同じコンカレンシー グループ内の現在実行中のジョブまたはワークフローをキャンセルするためにも `cancel-in-progress` を使用できます。\n\n```yaml\nname: Deployment\n\nconcurrency:\n  group: production\n  cancel-in-progress: true\n\non:\n  push:\n    branches:\n      - main\n\njobs:\n  deployment:\n    runs-on: ubuntu-latest\n    environment: production\n    steps:\n      - name: deploy\n        # ...deployment-specific steps\n```\n\nデプロイ固有の手順の記述に関するガイダンスについては、「[デプロイの検索の例](#finding-deployment-examples)」をご覧ください。\n\n## デプロイ履歴の表示\n\nGitHub Actions ワークフローが環境にデプロイされると、その環境がリポジトリのメイン ページに表示されます。 環境へのデプロイの表示について詳しくは、「[デプロイ履歴の表示](/ja/actions/how-tos/deploy/configure-and-manage-deployments/view-deployment-history)」をご覧ください。\n\n組織では、データを linked artifacts pageにアップロードすることで、すべてのビルドの展開レコードを 1 か所で収集できます。 「[リンクされた成果物について](/ja/code-security/concepts/supply-chain-security/linked-artifacts)」を参照してください。\n\n## ワークフローの実行の監視\n\nすべてのワークフローの実行は、実行の進行を示すリアルタイムのグラフを生成します。 このグラフを使って、デプロイを監視およびデバッグできます。 詳しくは、「[視覚化グラフの利用](/ja/actions/how-tos/monitor-workflows/use-the-visualization-graph)」を参照してください。\n\nまた、各ワークフロー実行のログとワークフロー実行の履歴を表示することもできます。 詳しくは、「[ワークフロー実行の履歴を表示する](/ja/actions/how-tos/monitor-workflows/view-workflow-run-history)」をご覧ください。\n\n## ワークフローでの必要なレビューの使用\n\n必須のレビュー担当者が設定された環境を参照するジョブは、開始前に承認を待ちます。 承認を待っている間のジョブは、ステータスが\"Waiting\"になります。 30 日以内に承認されないジョブは、自動的に失敗します。\n\n環境と必要な承認の詳細については、「[デプロイメント用の環境管理](/ja/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)」を参照してください。 REST API を使って配置を確認する方法については、「[ワークフロー実行の REST API エンドポイント](/ja/rest/actions/workflow-runs)」を参照してください。\n\n## カスタム デプロイ保護規則の使用\n\n> \\[!NOTE]\n> カスタム配置保護ルールは、現在 パブリック プレビュー 段階であり、変更される可能性があります。\n\n独自のカスタム保護規則を有効にして、サードパーティ サービスを使ったデプロイを制御できます。 たとえば、Datadog、Honeycomb、ServiceNow などのサービスを使用し、GitHub への展開に対して自動承認を提供できます。\n\nカスタムデプロイ保護規則は、 GitHub Apps によって強化され、Webhook とコールバックに基づいて実行されます。 ワークフロー ジョブの承認または拒否は、`deployment_protection_rule` Webhook の使用に基づいています。 詳細については、「[Webhook のイベントとペイロード](/ja/webhooks/webhook-events-and-payloads#deployment_protection_rule)」と「[配置の承認または拒否](/ja/actions/how-tos/deploy/configure-and-manage-deployments/create-custom-protection-rules#approving-or-rejecting-deployments)」を参照してください。\n\nカスタム デプロイ保護規則を作成し、リポジトリにインストールすると、リポジトリ内のすべての環境で自動的にカスタム デプロイ保護規則を使用できるようになります。\n\n環境へのデプロイは、IT サービス管理 (ITSM) システムで承認されたチケット、依存関係に対する脆弱性スキャン結果、クラウド リソースの安定した正常性メトリックなど、任意の外部サービスで定義された条件に基づいて承認または拒否できます。 デプロイの承認または拒否の判断は、統合するサードパーティのアプリケーションと、その中で定義する制御条件によって決まります。 デプロイ保護規則を作成できるユース ケースの一部を次に示します。\n\n* ITSM とセキュリティ オペレーション: デプロイの準備状況を確認する品質、セキュリティ、コンプライアンスのプロセスを確認することで、サービスの準備状況を確認できます。\n* 監視システム: モニタリングまたは監視システム (Asset Performance Management Systems、ログ アグリゲーター、クラウド リソースの正常性検証システムなど) を参考にして、安全性とデプロイの準備状況を確認できます。\n* コード品質とテスト ツール: 環境にデプロイする必要がある CI ビルドに対する自動テストを確認できます。\n\nまた、上記のユース ケースのいずれかに対して独自の保護規則を作成することや、運用前環境から運用環境へのデプロイを安全に承認または拒否するカスタム ロジックを定義することもできます。\n\n## アプリを使用したデプロイの追跡\n\nGitHub の個人アカウントまたは組織がMicrosoft Teamsまたは Slack と統合されている場合は、Microsoft Teamsまたは Slack を通じて環境を使用するデプロイを追跡できます。 たとえば、デプロイが承認保留中の場合、デプロイが承認された場合、またはデプロイの状態が変更された場合に、アプリを通じて通知を受け取ることができます。 Microsoft Teamsまたは Slack の統合の詳細については、「[おすすめのGitHub統合](/ja/integrations/concepts/featured-github-integrations#team-communication-tools) を参照してください。\n\nデプロイとデプロイの状態 Webhook を使用してデプロイを追跡するアプリを構築することもできます。\n環境を参照するワークフロー ジョブが実行されると、`environment` プロパティに環境の名前が設定された展開オブジェクトが作成されます。 ワークフローが進行すると、`environment` プロパティに環境の名前、`environment_url` プロパティに環境の URL (ワークフローで指定されている場合)、および `state` プロパティにジョブの状態が設定された展開状態オブジェクトも作成されます。 詳細については、 [GitHub Apps のドキュメント](/ja/apps) と [Webhook のイベントとペイロード](/ja/webhooks/webhook-events-and-payloads#deployment) を参照してください。\n\n## ランナーの選択\n\nデプロイ ワークフローは、 GitHubホストランナーまたはセルフホステッド ランナーで実行できます。\nGitHubホストランナーからのトラフィックは、[さまざまなネットワーク アドレス](/ja/rest/meta/meta#get-github-meta-information)から取得できます。 社内環境にデプロイしていて、会社が外部トラフィックをプライベート ネットワークに制限している場合、GitHub Actionsホストランナーで実行されているGitHubワークフローが内部サービスやリソースと通信できない可能性があります。 これを克服するために、独自のランナーをホストすることができます。 詳細については、「[セルフホステッド ランナー](/ja/actions/concepts/runners/self-hosted-runners)」および「[GitHub ホステッド ランナー](/ja/actions/concepts/runners/github-hosted-runners)」を参照してください。\n\n## 状態バッジを表示する\n\n状態バッジを使用して、デプロイ ワークフローの状態を表示できます。 ステータスバッジは、ワークフローが現在失敗しているかパスしているかを示します。 ステータス バッジは、リポジトリの `README.md` ファイル内に追加するのが一般的ですが、どの Web ページにも追加することができます。 デフォルトでは、バッジはデフォルトブランチのステータスを示します。 既定のブランチでワークフローの実行がない場合は、すべてのブランチで最新の実行状態が表示されます。 特定のブランチやイベントのワークフロー実行のステータスを、URL 内の `branch` および `event` クエリ パラメーターを使用して表示することもできます。\n\n![ワークフローの状態バッジのスクリーンショット。 右から左に、GitHub のロゴ、ワークフロー名 (\"GitHub Actions Demo\")、状態 (\"passing\") が表示されています。](/assets/images/help/repository/actions-workflow-status-badge.png)\n\n詳しくは、「[ワークフロー状態バッジの追加](/ja/actions/how-tos/monitor-workflows/add-a-status-badge)」をご覧ください。\n\n## デプロイメント例の発見\n\nこの記事では、デプロイ ワークフローに追加できる GitHub Actions の機能について説明しました。\n\nGitHubには、Azure Web App など、いくつかの一般的なサービス用のデプロイ ワークフロー テンプレートが用意されています。 ワークフロー テンプレートの基本的な使用方法については、「[ワークフロー テンプレートの使用](/ja/actions/how-tos/write-workflows/use-workflow-templates)」を参照するか、[配置ワークフロー テンプレートの完全な一覧を参照してください](https://github.com/actions/starter-workflows/tree/main/deployments)。 また、「[Azure App Serviceへの Node.js のデプロイ](/ja/actions/how-tos/deploy/deploy-to-third-party-platforms/nodejs-to-azure-app-service)」など、特定の配置ワークフローに関するより詳細なガイドをチェックすることもできます。\n\n多くのサービス プロバイダーは、サービスにデプロイするための GitHub Marketplace に対するアクションも提供しています。 完全な一覧については、 [GitHub Marketplace](https://github.com/marketplace?category=deployment\\&type=actions)を参照してください。"}