デプロイに環境の使用

環境について

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

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

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

デプロイ保護規則

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

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

必須のレビュー担当者

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

保護された環境への配置の自己レビューを禁止するオプションもあります。 この設定を有効にした場合、展開を開始するユーザーは、必須のレビュー担当者であっても、展開ジョブを承認できなくなります。 これにより、保護された環境への配置が常に複数のユーザーによってレビューされるようになります。

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

待機タイマー

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

配置ブランチとタグ

配置ブランチとタグを使って、環境に配置できるブランチとタグを制限します。 環境の配置ブランチとタグのオプションは次のとおりです。

• 制限なし: 環境にデプロイできるブランチまたはタグに制限はありません。

• Protected branches only: 環境に配置できるのは、ブランチ保護規則が有効なブランチのみです。 リポジトリ内のどのブランチにもブランチ保護ルールが定義されていない場合は、すべてのブランチをデプロイできます。 ブランチ保護ルールについて詳しくは、「保護されたブランチについて」をご覧ください。

  Note

  デプロイ ワークフローは、保護されたブランチと同じ名前のタグによってトリガーされ、保護されたブランチ名と一致するブランチを持つフォークは環境に配置できません。

• Selected branches and tags: 環境に配置できるのは、指定した名前パターンに一致するブランチとタグのみです。

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

  Note

  名前パターンは、ブランチまたはタグに対して個別に構成する必要があります。

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

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

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

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

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

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

環境シークレット

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

環境変数

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

環境の作成

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

1. GitHub で、リポジトリのメイン ページに移動します。

2. リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

3. 左側のサイドバーで、 [環境] をクリックします。

4. [新しい環境] をクリックします。

5. 環境の名前を入力し、 [環境の構成] をクリックします。 環境名では、大文字と小文字は区別されません。 環境名は255文字を超えてはならず、リポジトリ内でユニークでなければなりません。

6. 必要に応じて、この環境を使用するワークフロー ジョブを承認する必要があるユーザーまたはチームを指定します。 詳細については、「必須のレビュー担当者」を参照してください。

   1. [必要なレビュー担当者] を選択します。
   2. 最大 6 人のユーザーまたはチームを入力します。 ジョブが進行するため承認が必要なレビュー担当者は1人だけです。
   3. 必要に応じて、ユーザーがトリガーしたワークフローの実行を承認できないようにするには、[Prevent self-review] を選びます。
   4. [保護ルールの保存] をクリックします。

7. 必要に応じて、この環境を使用するワークフロー ジョブの続行を許可するまでの待機時間を指定します。 詳細については、「待機タイマー」を参照してください。

   1. [待機タイマー] を選択します。
   2. 待機する分数です。
   3. [保護ルールの保存] をクリックします。

8. 必要に応じて、構成された保護規則のバイパスを禁止します。 詳細については、「構成された保護規則を管理者がバイパスすることを許可する」を参照してください。

   1. [構成された保護規則を管理者がバイパスすることを許可する] をオフにします。
   2. [保護ルールの保存] をクリックします。

9. 必要に応じて、GitHub Apps を使って作成したカスタム デプロイ保護規則を有効にします。 詳細については、「カスタム配置保護規則」を参照してください。

   1. 有効にするカスタム保護規則を選びます。
   2. [保護ルールの保存] をクリックします。

10. 必要に応じて、この環境に配置できるブランチとタグを指定します。 詳細については、「配置ブランチとタグ」を参照してください。

    1. [デプロイ ブランチ] ドロップダウンで目的のオプションを選択します。

    2. [Selected branches and tags] を選んだ場合、新しい規則を追加するには、[Add deployment branch or tag rule] をクリックします

    3. [Ref type] ドロップダウン メニューで、適用する規則に応じて、[ Branch] または [ Tag] をクリックします。

    4. 許可するブランチまたはタグの名前パターンを入力します。

       Note

       名前パターンは、ブランチまたはタグに対して個別に構成する必要があります。

    5. [ルールの追加] をクリックします。

11. 必要に応じて、環境シークレットを追加します。 これらのシークレットは、環境を使用するワークフロー ジョブでのみ使用できます。 さらに、この環境を使用するワークフロー ジョブで、これらのシークレットにアクセスできるのは、構成済みのルール (必須のレビュー担当者など) が合格した後に限られています。 詳細については、「環境のシークレット」を参照してください。

    1. [環境シークレット] で、 [シークレットの追加] をクリックします。
    2. シークレット名を入力します。
    3. シークレット値を入力します。
    4. [シークレットの追加] をクリックします。

12. 必要に応じて、環境変数を追加します。 これらの変数は、その環境を使用するワークフロー ジョブでのみ利用でき、vars コンテキストを使用してのみアクセスできます。 詳細については、「環境変数」を参照してください。

    1. [環境変数] で [変数の追加] をクリックします。
    2. 変数名を入力します。
    3. 変数の値を入力します。
    4. [変数の追加] をクリックします。

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

存在しない環境を参照するワークフローを実行すると、参照された名前を持つ環境が作成されます。 暗黙的なページ ビルドの実行 (ブランチやフォルダー ソースなど) から環境が作成された場合、ソース ブランチは保護ルールとして環境に追加されます。 新しく作成される環境には、保護ルールやシークレットは設定されていません。 リポジトリのワークフローを編集できる人は、ワークフローファイルを通じて環境を作成できますが、その環境を設定できるのはリポジトリ管理者だけです。

環境の削除

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

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

1. GitHub で、リポジトリのメイン ページに移動します。

2. リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

   

3. 左側のサイドバーで、 [環境] をクリックします。

4. 削除する環境の横にある をクリックします。

5. [わかりました、この環境を削除してください] をクリックします。

REST API を介して環境を削除することもできます。 詳しくは、「リポジトリの REST API エンドポイント」をご覧ください。

環境とデプロイの関係

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

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

次のステップ

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