Managing environments for deployment

About environments

Environments are used to describe a general deployment target like production, staging, or development. When a GitHub Actions workflow deploys to an environment, the environment is displayed on the main page of the repository. For more information about viewing deployments to environments, see Viewing deployment history.

You can configure environments with protection rules and secrets. When a workflow job references an environment, the job won't start until all of the environment's protection rules pass. A job also cannot access secrets that are defined in an environment until all the deployment protection rules pass.

Optionally, you can bypass an environment's protection rules and force all pending jobs referencing the environment to proceed. For more information, see Reviewing deployments.

Deployment protection rules

Deployment protection rules require specific conditions to pass before a job referencing the environment can proceed. You can use deployment protection rules to require a manual approval, delay a job, or restrict the environment to certain branches. You can also create and implement custom protection rules powered by GitHub Apps to use third-party systems to control deployments referencing environments configured on GitHub.

Third-party systems can be observability systems, change management systems, code quality systems, or other manual configurations that you use to assess readiness before deployments are safely rolled out to environments.

Required reviewers

Use required reviewers to require a specific person or team to approve workflow jobs that reference the environment. You can list up to six users or teams as reviewers. The reviewers must have at least read access to the repository. Only one of the required reviewers needs to approve the job for it to proceed.

You also have the option to prevent self-reviews for deployments to protected environments. If you enable this setting, users who initiate a deployment cannot approve the deployment job, even if they are a required reviewer. This ensures that deployments to protected environments are always reviewed by more than one person.

For more information on reviewing jobs that reference an environment with required reviewers, see Reviewing deployments.

Wait timer

Use a wait timer to delay a job for a specific amount of time after the job is initially triggered. The time (in minutes) must be an integer between 1 and 43,200 (30 days). Wait time will not count towards your billable time.

Deployment branches and tags

Use deployment branches and tags to restrict which branches and tags can deploy to the environment. Below are the options for deployment branches and tags for an environment:

• No restriction: No restriction on which branch or tag can deploy to the environment.

• Protected branches only: Only branches with branch protection rules enabled can deploy to the environment. If no branch protection rules are defined for any branch in the repository, then all branches can deploy. For more information about branch protection rules, see 保護されたブランチについて.

  メモ

  Deployment workflow runs triggered by tags with the same name as a protected branch and forks with branches that match the protected branch name cannot deploy to the environment.

• Selected branches and tags: Only branches and tags that match your specified name patterns can deploy to the environment.

  If you specify releases/* as a deployment branch or tag rule, only a branch or tag whose name begins with releases/ can deploy to the environment. (Wildcard characters will not match /. To match branches or tags that begin with release/ and contain an additional single slash, use release/*/*.) If you add main as a branch rule, a branch named main can also deploy to the environment. For more information about syntax options for deployment branches, see the Ruby File.fnmatch documentation.

  メモ

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

Allow administrators to bypass configured protection rules

By default, administrators can bypass the protection rules and force deployments to specific environments. For more information, see Reviewing deployments.

Alternatively, you can configure environments to disallow bypassing the protection rules for all deployments to the environment.

Custom deployment protection rules

独自のカスタム保護規則を有効にして、サードパーティ サービスを使ったデプロイを制御できます。 たとえば、Datadog、Honeycomb、ServiceNow などのサービスを使用し、GitHub への展開に対して自動承認を提供できます。 For more information, see Creating custom deployment protection rules.

Once custom deployment protection rules have been created and installed on a repository, you can enable the custom deployment protection rule for any environment in the repository. For more information about configuring and enabling custom deployment protection rules, see Configuring custom deployment protection rules.

Environment secrets

Secrets stored in an environment are only available to workflow jobs that reference the environment. If the environment requires approval, a job cannot access environment secrets until one of the required reviewers approves it. For more information about secrets, see シークレットについて.

Environment variables

Variables stored in an environment are only available to workflow jobs that reference the environment. These variables are only accessible using the vars context. For more information, see Store information in variables.

Creating an environment

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

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

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

   

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

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

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

6. Optionally, specify people or teams that must approve workflow jobs that use this environment. For more information, see Required reviewers.

   1. Select Required reviewers.
   2. Enter up to 6 people or teams. Only one of the required reviewers needs to approve the job for it to proceed.
   3. Optionally, to prevent users from approving workflows runs that they triggered, select Prevent self-review.
   4. Click Save protection rules.

7. Optionally, specify the amount of time to wait before allowing workflow jobs that use this environment to proceed. For more information, see Wait timer.

   1. Select Wait timer.
   2. Enter the number of minutes to wait.
   3. Click Save protection rules.

8. Optionally, disallow bypassing configured protection rules. For more information, see Allow administrators to bypass configured protection rules.

   1. Deselect Allow administrators to bypass configured protection rules.
   2. Click Save protection rules.

9. Optionally, enable any custom deployment protection rules that have been created with GitHub Apps. For more information, see Custom deployment protection rules.

   1. Select the custom protection rule you want to enable.
   2. Click Save protection rules.

10. Optionally, specify what branches and tags can deploy to this environment. For more information, see Deployment branches and tags.

    1. Select the desired option in the Deployment branches dropdown.

    2. If you chose Selected branches and tags, to add a new rule, click Add deployment branch or tag rule

    3. In the "Ref type" dropdown menu, depending on what rule you want to apply, click Branch or Tag.

    4. Enter the name pattern for the branch or tag that you want to allow.

       メモ

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

    5. Click Add rule.

11. Optionally, add environment secrets. These secrets are only available to workflow jobs that use the environment. Additionally, workflow jobs that use this environment can only access these secrets after any configured rules (for example, required reviewers) pass. For more information, see Environment secrets.

    1. Under Environment secrets, click Add Secret.
    2. Enter the secret name.
    3. Enter the secret value.
    4. Click Add secret.

12. Optionally, add environment variables. These variables are only available to workflow jobs that use the environment, and are only accessible using the vars context. For more information, see Environment variables.

    1. Under Environment variables, click Add Variable.
    2. Enter the variable name.
    3. Enter the variable value.
    4. Click Add variable.

You can also create and configure environments through the REST API. For more information, see Deployment Environments 用 REST API エンドポイント, GitHub Actions シークレットの REST API エンドポイント, GitHub Actions 変数の REST API エンドポイント, and デプロイ ブランチ ポリシー用の REST API エンドポイント.

Running a workflow that references an environment that does not exist will create an environment with the referenced name. If the environment is created from running implicit page builds (for example, from a branch or folder source), the source branch will be added as a protection rule to the environment. Otherwise, the newly created environment will not have any protection rules or secrets configured. Anyone that can edit workflows in the repository can create environments via a workflow file, but only repository admins can configure the environment.

Deleting an environment

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

Deleting an environment will delete all secrets and protection rules associated with the environment. Any jobs currently waiting because of protection rules from the deleted environment will automatically fail.

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

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

   

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

4. Next to the environment that you want to delete, click .

5. Click I understand, delete this environment.

You can also delete environments through the REST API. For more information, see リポジトリの REST API エンドポイント.

How environments relate to deployments

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

You can access these objects through the REST API or GraphQL API. You can also subscribe to these webhook events. For more information, see リポジトリの REST API エンドポイント, オブジェクト (GraphQL API), or Webhook のイベントとペイロード.

Next steps

GitHub Actions provides several features for managing your deployments. For more information, see GitHub Actions を使用してデプロイする.