Skip to main content

此版本的 GitHub Enterprise Server 将于以下日期停止服务 2024-08-29. 即使针对重大安全问题,也不会发布补丁。 为了获得更好的性能、更高的安全性和新功能,请升级到最新版本的 GitHub Enterprise。 如需升级帮助,请联系 GitHub Enterprise 支持

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

所有现行 GitHub 计划的公共存储库中都提供环境、环境机密和部署保护规则。 旧版计划(如 Bronze、Silver 或 Gold)中不提供这些内容。 要访问专用存储库或内部存储库中的环境、环境机密和部署分支,必须使用 GitHub Pro、GitHub Team 或 GitHub Enterprise 。

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 "审查部署."

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 Enterprise Server 实例.

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.

For more information on reviewing jobs that reference an environment with required reviewers, see "审查部署."

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

Deployment branches

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

  • All branches: All branches in the repository can deploy to the environment.

  • Protected branches: 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 "关于受保护分支."

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

    If you specify releases/* as a deployment branch rule, only a branch whose name begins with releases/ can deploy to the environment. (Wildcard characters will not match /. To match branches 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 "审查部署."

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

Custom deployment protection rules

注意****:自定义部署保护规则目前为公共 beta 版本,可能随时变动。

可以启用自己的自定义保护规则来限制第三方服务的部署。 例如,可以使用 Datadog、Honeycomb 和 ServiceNow 等服务为部署到 你的 GitHub Enterprise Server 实例 提供自动审批。 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 "配置自定义部署保护规则."

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 中使用机密."

Note: 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 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 "变量."

Creating an environment

要在个人帐户存储库中配置环境,你必须是存储库所有者。 若要在组织存储库中配置环境,必须具有 admin 访问权限。

  1. 在 你的 GitHub Enterprise Server 实例 上,导航到存储库的主页。

  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. 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 can deploy to this environment. For more information, see "Deployment branches."

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

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

    3. Enter the name pattern for the branch that you want to allow.

    4. 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 "适用于部署环境的 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 Enterprise Server 实例 上,导航到存储库的主页。

  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 进行部署."