デプロイに環境を使用する

環境について

環境は、一般的なデプロイターゲットを記述するために使用されます (例: production、staging、または development)。 GitHub Actions ワークフローが環境にデプロイされると、その環境がリポジトリのメインページに表示されます。環境へのデプロイの表示について詳しくは、「デプロイ履歴の表示」を参照してください。

保護ルールとシークレットを持つ環境を設定できます。ワークフローのジョブが環境を参照すると、その環境の保護ルールをすべてパスするまではジョブは開始されません。すべてのデプロイ保護規則をパスするまで、ジョブは環境で定義されているシークレットにアクセスできません。

必要に応じて、環境の保護ルールをバイパスし、その環境を参照しているすべての保留中のジョブを強制的に進行させることができます。詳細については、「デプロイメントのレビュー」を参照してください。

デプロイ保護規則

デプロイ保護規則は、その環境を参照するジョブを先に進める前に、特定の条件を満たすことを要求するものです。デプロイ保護規則を使って、手動の承認を必須にすること、ジョブを遅延させること、または環境を特定のブランチに制限することができます。また、GitHub Apps を利用するカスタム保護規則を作成して実装し、GitHub.com に構成された環境を参照するデプロイを制御するためにサードパーティシステムを使用することができます。

サードパーティシステムは、監視システム、変更管理システム、コード品質システム、デプロイを安全に環境にロールアウトする前に準備状況を評価するために使うその他の手動構成などです。

注: 任意の数の GitHub Apps ベースのデプロイ保護規則をリポジトリにインストールできます。ただし、どの環境でも、同時に有効にできるデプロイ保護規則は最大 6 つです。

必須のレビュー担当者

必須のレビュー担当者を使って、特定の人もしくはTeamがその環境を参照するワークフローのジョブを承認しなければならないようにすることができます。最大で6人のユーザもしくはTeamをレビュー担当者とすることができます。レビュー担当者は、少なくともそのリポジトリの読み取りアクセス権を持っていなければなりません。ジョブが進行するため承認が必要なレビュー担当者は1人だけです。

レビュー担当者を必要とする環境を参照するジョブの確認方法の詳細については、「デプロイメントのレビュー」を参照してください。

待機タイマー

ジョブが最初にトリガーされた後、特定の時間ジョブを遅延させるために、待機タイマーを使ってください。時間（分）は、0から43,200（30日）の間の整数でなければなりません。

デプロイメントブランチ

デプロイメントブランチを使用して、環境にデプロイできるブランチを制限します。環境のデプロイメントブランチのオプションは以下のとおりです。

すべてのブランチ: リポジトリ内のすべてのブランチを環境にデプロイできます。
保護されたブランチ: 環境にデプロイできるのはブランチ保護ルールが有効になっているブランチのみです。リポジトリ内のどのブランチにもブランチ保護ルールが定義されていない場合は、すべてのブランチをデプロイできます。ブランチ保護規則の詳細については、「保護されたブランチについて」を参照してください。
選択したブランチ: 環境にデプロイできるのは指定した名前パターンに一致するブランチのみです。

たとえば、デプロイブランチルールとして releases/* を指定した場合、名前が releases/ で始まるブランチのみが環境にデプロイできます。 (ワイルドカード文字は / と一致しません。 release/ で始まり、追加の単一スラッシュを含むブランチを一致させるには、release/*/* を使用します)。main をデプロイブランチルールとして追加すると、main という名前のブランチも環境にデプロイできます。デプロイブランチの構文オプションの詳細については、Ruby File.fnmatch のドキュメントを参照してください。

構成された保護規則を管理者がバイパスすることを許可する

既定では、管理者は保護規則をバイパスし、特定の環境へのデプロイを強制できます。詳しくは、「デプロイメントのレビュー」を参照してください。

また、環境へのすべてのデプロイに対して保護規則のバイパスを禁止するように環境を構成することもできます。

カスタムデプロイ保護規則

注: 現在、カスタムデプロイ保護規則はパブリックベータ版であり、変更される可能性があります。

独自のカスタム保護規則を有効にして、サードパーティサービスを使ったデプロイを制御できます。たとえば、Datadog、Honeycomb、ServiceNow などのサービスを使って、GitHub.com へのデプロイに対して自動承認を提供できます。詳細については、「カスタムデプロイ保護規則の作成」を参照してください。

カスタムデプロイ保護規則を作成してリポジトリにインストールすると、リポジトリ内の任意の環境に対してカスタムデプロイ保護規則を有効にすることができます。カスタムデプロイ保護規則の構成と有効化の詳細については、「カスタムデプロイ保護規則の構成」を参照してください。

環境シークレット

環境に保存されたシークレットは、その環境を参照するワークフロージョブからのみ利用できます。環境が承認を必要とするなら、ジョブは必須のレビュー担当者の一人が承認するまで環境のシークレットにアクセスできません。シークレットについて詳しくは、「GitHub Actions でのシークレットの使用」をご覧ください。

注: セルフホストランナーで実行されるワークフローは、環境を使用している場合でも、分離されたコンテナーでは実行されません。環境シークレットは、リポジトリおよび Organization シークレットと同じレベルのセキュリティで処理する必要があります。詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。

環境変数

環境に保存された変数は、その環境を参照するワークフロージョブからのみ利用できます。これらの変数には、vars コンテキストを使用してのみアクセスできます。詳しくは、「変数」を参照してください。

環境の作成

個人アカウントのリポジトリで環境を設定するには、リポジトリの所有者である必要があります。組織のリポジトリに環境を設定するには、admin アクセスが必要です。

GitHub.com で、リポジトリのメインページへ移動します。
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウンメニューを選び、 [設定] をクリックします。
左側のサイドバーで、 [環境] をクリックします。
[新しい環境] をクリックします。
環境の名前を入力し、 [環境の構成] をクリックします。環境名では、大文字と小文字は区別されません。環境名は255文字を超えてはならず、リポジトリ内でユニークでなければなりません。
必要に応じて、この環境を使用するワークフロージョブを承認する必要があるユーザーまたはチームを指定します。詳しくは、「必要なレビュー」を参照してください。
1. [必要なレビュー担当者] を選択します。
2. 最大 6 人のユーザーまたはチームを入力します。ジョブが進行するため承認が必要なレビュー担当者は1人だけです。
3. [保護ルールの保存] をクリックします。
必要に応じて、この環境を使用するワークフロージョブの続行を許可するまでの待機時間を指定します。詳細については、「待機タイマー」を参照してください。
1. [待機タイマー] を選択します。
2. 待機する分数です。
3. [保護ルールの保存] をクリックします。
必要に応じて、構成された保護規則のバイパスを禁止します。詳細については、「構成された保護規則を管理者がバイパスすることを許可する」を参照してくだい。
1. [構成された保護規則を管理者がバイパスすることを許可する] をオフにします。
2. [保護ルールの保存] をクリックします。
必要に応じて、GitHub Apps を使って作成したカスタムデプロイ保護規則を有効にします。詳細については、「カスタムデプロイ保護規則」を参照してください。
1. 有効にするカスタム保護規則を選びます。
2. [保護ルールの保存] をクリックします。
必要に応じて、この環境にデプロイできるブランチを指定します。詳細については、「デプロイブランチ」を参照してください。
1. [デプロイブランチ] ドロップダウンで目的のオプションを選択します。
2. [選択したブランチ] を選択した場合は、許可するブランチ名パターンを入力します。
必要に応じて、環境シークレットを追加します。これらのシークレットは、環境を使用するワークフロージョブでのみ使用できます。さらに、この環境を使用するワークフロージョブで、これらのシークレットにアクセスできるのは、構成済みのルール (必須のレビュー担当者など) が合格した後に限られています。詳細については、「環境のシークレット」を参照してください。
1. [環境シークレット] で、 [シークレットの追加] をクリックします。
2. シークレット名を入力します。
3. シークレット値を入力します。
4. [シークレットの追加] をクリックします。
必要に応じて、環境変数を追加します。これらの変数は、その環境を使用するワークフロージョブでのみ利用でき、vars コンテキストを使用してのみアクセスできます。詳しくは、「環境変数」をご覧ください。
1. [環境変数] で [変数の追加] をクリックします。
2. 変数名を入力します。
3. 変数の値を入力します。
4. [変数の追加] をクリックします。

REST API を介して環境を作成および設定することもできます。詳しくは、「デプロイ環境」、「GitHub Actions のシークレット」、「GitHub Actions の変数」、「デプロイブランチポリシー」を参照してください。

存在しない環境を参照するワークフローを実行すると、参照された名前を持つ環境が作成されます。新しく作成される環境には、保護ルールやシークレットは設定されていません。リポジトリのワークフローを編集できる人は、ワークフローファイルを通じて環境を作成できますが、その環境を設定できるのはリポジトリ管理者だけです。

環境の使用

ワークフロー中の各ジョブは、1つの環境を参照できます。その環境を参照するジョブがランナーに送信される前に、その環境に設定された保護ルールはパスしなければなりません。ジョブがランナーに送信された後でのみ、ジョブは環境のシークレットにアクセスできます。

ワークフローが環境を参照する場合、その環境はリポジトリのデプロイメントに現れます。現在と以前のデプロイを表示する方法について詳しくは、「デプロイ履歴の表示」を参照してください。

ワークフロー内のジョブごとに環境を指定できます。そのためには jobs.<job_id>.environment キーを追加し、その後に環境の名前を追加します。

たとえば、このワークフローでは production という環境が使用されます。

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: deploy
        # ...deployment-specific steps

上記のワークフローを実行すると、 deployment ジョブは production 環境用に構成されたすべてのルールに従います。たとえば、環境でレビュー担当者が必要な場合、いずれかのレビュー担当者がジョブを承認するまでジョブは一時停止します。

環境の URL を指定することもできます。指定した URL は、リポジトリのデプロイページ (リポジトリのホームページの [環境] をクリックすることでアクセス可能) とワークフロー実行の視覚化グラフに表示されます。 pull request がワークフローをトリガーすると、URL は pull request タイムラインの [デプロイの表示] ボタンとしても表示されます。

name: Deployment

on:
  push:
    branches:
      - main

jobs:
  deployment:
    runs-on: ubuntu-latest
    environment: 
      name: production
      url: https://github.com
    steps:
      - name: deploy
        # ...deployment-specific steps

環境の削除

個人アカウントのリポジトリで環境を設定するには、リポジトリの所有者である必要があります。組織のリポジトリに環境を設定するには、admin アクセスが必要です。

環境を削除すると、その環境に関連づけられたすべてのシークレットと保護ルールが削除されます。削除された環境の保護ルールのために待機していたジョブは、自動的に失敗します。

GitHub.com で、リポジトリのメインページへ移動します。
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウンメニューを選び、 [設定] をクリックします。
左側のサイドバーで、 [環境] をクリックします。
削除する環境の横にあるをクリックします。
[わかりました、この環境を削除してください] をクリックします。

REST API を介して環境を削除することもできます。詳しくは、「リポジトリ」を参照してください。

環境とデプロイの関係

環境を参照するワークフロージョブが実行されると、environment プロパティに環境の名前が設定された展開オブジェクトが作成されます。ワークフローが進行すると、environment プロパティに環境の名前、environment_url プロパティに環境の URL (ワークフローで指定されている場合)、および state プロパティにジョブの状態が設定された展開状態オブジェクトも作成されます。

これらのオブジェクトには、REST API または GraphQL API を介してアクセスできます。これらの Webhook イベントをサブスクライブすることもできます。詳しくは、「リポジトリ」(REST API)、「オブジェクト」(GraphQL API)、または「Webhook のイベントとペイロード」を参照してください。

次の手順

GitHub Actions には、デプロイを管理するためのいくつかの機能が用意されています。詳しくは、「GitHub Actions を使用してデプロイする」を参照してください。

デプロイに環境を使用する

この記事の内容