Managing environments for deployment

You can create environments and secure those environments with deployment protection rules. A job that references an environment must follow any protection rules for the environment before running or accessing the environment's secrets.

누가 이 기능을 사용할 수 있나요?

Repository owners

Environments, environment secrets, and deployment protection rules are available in public repositories for all current GitHub plans. They are not available on legacy plans, such as Bronze, Silver, or Gold. For access to environments, environment secrets, and deployment branches in private or internal repositories, you must use GitHub Pro, GitHub Team, or GitHub Enterprise. If you are on a GitHub Free, GitHub Pro, or GitHub Team plan, other deployment protection rules, such as a wait timer or required reviewers, are only available for public repositories.

이 문서의 내용

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 "배포 기록 보기."

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 "배포 검토."

Note: Users with GitHub Free plans can only configure environments for public repositories. If you convert a repository from public to private, any configured protection rules or environment secrets will be ignored, and you will not be able to configure any environments. If you convert your repository back to public, you will have access to any previously configured protection rules and environment secrets.

Organizations with GitHub Team and users with GitHub Pro can configure environments for private repositories. For more information, see "GitHub의 플랜."

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.com.

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.

참고: 리포지토리에 GitHub Apps 기반 배포 보호 규칙을 원하는 만큼 설치할 수 있습니다. 하지만 환경에 상관없이 배포 보호 규칙은 동시에 6개까지만 사용하도록 설정할 수 있습니다.

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 "배포 검토."

Note: If you are on a GitHub Free, GitHub Pro, or GitHub Team plan, required reviewers are only available for public repositories.

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).

Note: If you are on a GitHub Free, GitHub Pro, or GitHub Team plan, wait timers are only available for public repositories.

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 "보호된 분기 정보."

    Note: 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.

    참고: 이름 패턴은 분기 또는 태그에 대해 개별적으로 구성해야 합니다.

Note: Deployment branches and tags are available for all public repositories. For users on GitHub Pro or GitHub Team plans, deployment branches and tags are also available for private repositories.

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 "배포 검토."

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

Note: Allowing administrators to bypass protection rules is only available for public repositories for users on GitHub Free, GitHub Pro, and GitHub Team plans.

Custom deployment protection rules

참고: 태그 보호 규칙은 현재 베타 버전으로 변경될 수 있습니다.

타사 서비스를 사용하여 배포를 제어하는 사용자 지정 보호 규칙을 사용하도록 설정할 수 있습니다. 예를 들어 Datadog, Honeycomb 및 ServiceNow와 같은 서비스를 사용하여 GitHub.com에 대한 배포에 자동화된 승인을 제공할 수 있습니다. For more information, see "사용자 지정 배포 보호 규칙 만들기".

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 "사용자 지정 배포 보호 규칙 구성."

Note: Custom deployment protection rules are only available for public repositories for users on GitHub Free, GitHub Pro, and GitHub Team plans.

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 "GitHub Actions에서 비밀 사용."

Notes:

  • Workflows that run on self-hosted runners are not run in an isolated container, even if they use environments. Environment secrets should be treated with the same level of security as repository and organization secrets. For more information, see "GitHub Actions에 대한 보안 강화."
  • Environment secrets are only available in public repositories if you are using GitHub Free. For access to environment secrets in private or internal repositories, you must use GitHub Pro, GitHub Team, or GitHub Enterprise. For more information on switching your plan, 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 "변수."

Note: Environment variables are available for all public repositories. For users on GitHub Pro or GitHub Team plans, environment variables are also available for private repositories.

Creating an environment

개인 계정 리포지토리에서 환경을 구성하려면 리포지토리 소유자여야 합니다. 조직 리포지토리에서 환경을 구성하려면 admin 액세스 권한이 있어야 합니다.

Notes:

  • Creation of an environment in a private repository is available to organizations with GitHub Team and users with GitHub Pro.
  • Some features for environments have no or limited availability for private repositories. If you are unable to access a feature described in the instructions below, please see the documentation linked in the related step for availability information.

  1. GitHub.com에서 리포지토리의 기본 페이지로 이동합니다.

  2. 리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

    탭을 보여 주는 리포지토리 헤더의 스크린샷. "설정" 탭이 진한 주황색 윤곽선으로 강조 표시됩니다.

  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. 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.com에서 리포지토리의 기본 페이지로 이동합니다.

  2. 리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.

    탭을 보여 주는 리포지토리 헤더의 스크린샷. "설정" 탭이 진한 주황색 윤곽선으로 강조 표시됩니다.

  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 속성, 환경의 URL로 설정된 environment_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 "웹후크 이벤트 및 페이로드."

Next steps

GitHub Actions provides several features for managing your deployments. For more information, see "GitHub Actions를 사용하여 배포."