Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-10-12. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい

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

保護ルールとシークレットを持つ環境を設定できます。 環境を参照するワークフロー ジョブは、環境のシークレットを実行またはそれにアクセスする前に、環境の保護ルールに従う必要があります。

環境、環境のシークレット、環境保護ルールは、すべての製品の パブリック リポジトリで利用できます。 プライベート または 内部 リポジトリ内の環境、環境のシークレット、デプロイ ブランチにアクセスするには、GitHub Pro、GitHub Team または GitHub Enterprise を使う必要があります。 プライベート または 内部 リポジトリ内の他の環境保護ルールにアクセスする� �合は、GitHub Enterprise を使う必要があります。

環境について

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

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

環境保護ルール

環境の保護ルールは、その環境を参照しているジョブが進行する前に特定の条件をパスすることを要求します。 環境の保護ルールでは、手動による承認を要求したり、ジョブを遅延させたり、環境を特定のブランチに制限したりすることができます。

必� �のレビュー担当者

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

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

待機タイマー

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

デプロイメントブランチ

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

  • すべてのブランチ: リポジトリ内のすべてのブランチを環境にデプロイできます。

  • 保護されたブランチ: 環境にデプロイできるのはブランチ保護ルールが有効になっているブランチのみです。 リポジトリ内のどのブランチにもブランチ保護ルールが定義されていない� �合は、すべてのブランチをデプロイできます。 ブランチ保護ルールの詳細については、「保護されたブランチについて」を参照してく� さい。

  • 選択したブランチ: 環境にデプロイできるのは指定した名前パターンに一致するブランチのみです。

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

環境シークレット

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

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

環境の作成

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

  1. On your GitHub Enterprise Server instance, navigate to the main page of the repository. 1. リポジトリ名の下の [ 設定] をクリックします。 リポジトリの設定ボタン 1. 左側のサイドバーで、 [環境] をクリックします。 1. [新しい環境] をクリックします。 1. 環境の名前を入力し、 [環境の構成] をクリックします。 環境名では、大文字と小文字は区別されません。 環境名は255文字を超えてはならず、リポジトリ内でユニークでなければなりません。
  2. 必要に応じて、この環境を使用するワークフロー ジョブを承認する必要があるユーザーまたはチー� を指定します。
    1. [必要なレビュー担当者] を選択します。
    2. 最大 6 人のユーザーまたはチー� を入力します。 ジョブが進行するため承認が必要なレビュー担当者は1人� けです。
    3. [保護ルールの保存] をクリックします。
  3. 必要に応じて、この環境を使用するワークフロー ジョブの続行を許可するまでの待機時間を指定します。
    1. [待機タイマー] を選択します。
    2. 待機する分数です。
    3. [保護ルールの保存] をクリックします。
  4. 必要に応じて、この環境にデプロイできるブランチを指定します。 使用可能な値の詳細については、「デプロイ ブランチ」を参照してく� さい。
    1. [デプロイ ブランチ] ドロップダウンで目的のオプションを選択します。
    2. [選択したブランチ] を選択した� �合は、許可するブランチ名パターンを入力します。
  5. 必要に応じて、環境シークレットを追� します。 これらのシークレットは、環境を使用するワークフロー ジョブでのみ使用できます。 さらに、この環境を使用するワークフロー ジョブで、これらのシークレットにアクセスできるのは、構成済みのルール (必� �のレビュー担当者など) が合� �した後に限られています。 シークレットの詳細については、「暗号化されたシークレット」を参照してく� さい。
    1. [環境シークレット] で、 [シークレットの追� ] をクリックします。
    2. シークレット名を入力します。
    3. シークレット値を入力します。
    4. [シークレットの追� ] をクリックします。

REST API を介して環境を作成および設定することもできます。 詳しくは、「デプロイ環境」、「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

URL を含むワークフロー グラフ

環境の削除

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

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

  1. On your GitHub Enterprise Server instance, navigate to the main page of the repository. 1. リポジトリ名の下の [ 設定] をクリックします。 リポジトリの設定ボタン 1. 左側のサイドバーで、 [環境] をクリックします。
  2. 削除する環境の横にある をクリックします。
  3. [わかりました、この環境を削除してく� さい] をクリックします。

REST API を介して環境を削除することもできます。 詳しくは、環境に関するページを参照してく� さい。

環境とデプロイの関係

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

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

次の手� �

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