Skip to main content

使用环境进行部署

您可以使用保护规则和机密配置环境。 引用环境的工作流程作业在运行或访问环境的机密之前,必须遵循环境的任何保护规则。

谁可以使用此功能?

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

关于环境

环境用于描述常规部署目标,例如 productionstagingdevelopment。 当 GitHub Actions 工作流部署到某个环境时,该环境将显示在存储库的主页上。 有关如何查看环境部署的详细信息,请参阅“查看部署历史记录”。

您可以使用保护规则和机密配置环境。 当工作流程引用环境时,作业在环境的所有保护规则通过之前不会开始。 在所有部署保护规则通过之前,作业也不能访问在环境中定义的机密。

(可选)可以绕过环境的保护规则,强制所有引用该环境的挂起作业继续操作。 有关详细信息,请参阅“审查部署”。

部署保护规则

部署保护规则要求通过特定的条件,然后引用环境的作业才能继续。 可以使用部署保护规则要求手动批准、延迟作业或将环境限制为某些分支。还可以创建并实现由 GitHub Apps 提供支持的自定义保护规则,以使用第三方系统来控制引用在 GitHub.com 上配置的环境的部署。

第三方系统可以是可观测性系统、变更管理系统、代码质量系统或其他手动配置,用于在将部署安全部署到环境之前评估就绪情况。

注意:可以在存储库中安装任意数量的基于 GitHub Apps 的部署保护规则。 但是,最多可以同时在环境中启用 6 个部署保护规则。

需要的审查者

使用所需的审查者要求特定人员或团队批准引用环境的工作流程作业。 您最多可以列出六个用户或团队作为审查者。 审查者必须至少具有对仓库的读取访问权限。 只有一个必需的审查者需要批准该作业才能继续。

还可以选择阻止对受保护环境的部署进行自我评审。 如果启用此设置,则启动部署的用户将无法批准部署作业,即使他们是必需的审阅者也是如此。 这可确保对受保护环境的部署始终经过多人评审。

有关由必需审查者审查引用环境的作业的详细信息,请参阅“审查部署”。

等待计时器

在最初触发作业后,使用等待计时器将作业延迟特定时间。 时间(分钟)必须是 0 至 43,200(30天)之间的整数。

部署分支和标签

使用部署分支和标签来限制哪些分支和标签可以部署到环境。 下面是适用于环境的部署分支和标签的选项:

  • 无限制****:对于可以部署到环境中的分支或标记无限制。

  • 仅限受保护的分支:仅能将启用了分支保护规则的分支部署到环境。**** 如果没有为仓库中的任何分支定义分支保护规则,那么所有分支都可以部署。 有关分支保护规则的详细信息,请参阅“关于受保护分支”。

    注意: 部署工作流运行由与受保护分支同名的标记触发,并且与受保护分支名称匹配的分支无法部署到环境中。

  • 选定分支和标签:只能将与指定名称模式匹配的分支和标签部署到环境。****

    如果将 releases/* 指定为部署分支或标签规则,则只有名称以 releases/ 开头的分支或标签可以部署到环境。 (通配符不匹配 /。 要匹配以 release/ 开头且包含其他单斜杠的分支或标签,请使用 release/*/*。如果添加 main 作为分支规则,则名为 main 的分支也可以部署到环境。 有关部署分支的语法选项的详细信息,请参阅 Ruby File.fnmatch 文档

    注意:必须单独为分支或标记配置名称模式。****

允许管理员绕过配置的保护规则

默认情况下,管理员可以绕过保护规则,并强制部署到特定环境。 有关详细信息,请参阅“审查部署”。

或者,可以将环境配置为禁止绕过环境的所有部署保护规则。

自定义部署保护规则

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

可以启用自己的自定义保护规则来限制第三方服务的部署。 例如,可以使用 Datadog、Honeycomb 和 ServiceNow 等服务为部署到 GitHub.com 提供自动审批。有关详细信息,请参阅“创建自定义部署保护规则”。

在存储库上创建自定义部署保护规则并安装后,可以为存储库中的任何环境启用自定义部署保护规则。 有关配置和启用自定义部署保护规则的详细信息,请参阅“配置自定义部署保护规则”。

环境机密

存储在环境中的机密仅可用于引用环境的工作流程作业。 如果环境需要批准,作业在所需的审查者批准之前不能访问环境机密。 有关机密的详细信息,请参阅“在 GitHub Actions 中使用机密”。

注意:在自托管运行器上运行的工作流不会在一个孤立的容器中运行,即使它们使用环境。 环境机密应与存储库和组织机密的安全级别相同。 有关详细信息,请参阅“GitHub Actions 的安全强化”。

环境变量

存储在环境中的变量仅可用于引用环境的工作流作业。 只能使用 vars 上下文访问这些变量。 有关详细信息,请参阅“变量”。

创建环境

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

  1. 在 GitHub.com 上,导航到存储库的主页。

  2. 在存储库名称下,单击 “设置”。 如果看不到“设置”选项卡,请选择“”下拉菜单,然后单击“设置”********。

    存储库标头的屏幕截图,其中显示了选项卡。 “设置”选项卡以深橙色边框突出显示。

  3. 在左侧边栏中,单击“环境”。

  4. 单击“新建环境”。

  5. 为环境输入一个名称, 然后单击“配置环境”。 环境名称不区分大小写。 环境名称不能超过 255 个字符,且必须在仓库中唯一。

  6. (可选)指定必须批准使用此环境的工作流程作业的人员或团队。 有关详细信息,请参阅“必需的审阅者”。

    1. 选择“必需审阅者”。
    2. 最多可输入 6 人或团队。 只有一个必需的审查者需要批准该作业才能继续。
    3. (可选)若要防止用户批准其触发的工作流运行,请选择“阻止自我评审”。
    4. 单击“保存保护规则”。
  7. (可选)指定在允许使用此环境的工作流程作业继续之前要等待的时长。 有关详细信息,请参阅“等待计时器”。

    1. 选择“等待计时器”。
    2. 输入要等待的分钟数。
    3. 单击“保存保护规则”。
  8. (可选)禁止绕过配置的保护规则。 有关详细信息,请参阅“允许管理员绕过配置的保护规则”。

    1. 取消选择“允许管理员绕过配置的保护规则”。
    2. 单击“保存保护规则”。
  9. (可选)启用使用 GitHub Apps 创建的任何自定义部署保护规则。 有关详细信息,请参阅“自定义部署保护规则”。

    1. 选择要启用的自定义保护规则。
    2. 单击“保存保护规则”。
  10. 也可以选择性地指定哪些分支和标签可以部署到此环境。 有关详细信息,请参阅“部署分支和标签。”

    1. 在“部署分支”下拉列表中选择所需的选项。

    2. 如果选择了“选定分支和标签”,若要添加新规则,请按下“添加部署分支或标签规则”******** 在“Ref 类型”下拉菜单中,根据要应用的规则,按下“ 分支”或“ 标签”。********

    3. 输入想要允许的分支或标签的名称模式。

      注意:必须单独为分支或标记配置名称模式。****

    4. 单击 “添加规则”

  11. (可选)添加环境机密。 这些机密仅可用于使用环境的工作流程作业。 此外,使用此环境的工作流程作业只能在任何配置的规则(例如,必需的审查者)通过后才能访问这些机密。 有关详细信息,请参阅“环境机密”。

    1. 在“环境机密”下,单击“添加机密” 。
    2. 输入机密名称。
    3. 输入机密值。
    4. 单击“添加机密”。
  12. (可选)添加环境变量。 这些变量仅可用于使用环境的工作流作业,并且只能通过 vars 上下文访问。 有关详细信息,请参阅“环境变量”。

    1. 在“环境变量”下,单击“添加变量” 。
    2. 输入变量名称。
    3. 输入变量的值。
    4. 单击“添加变量”。

您还可以通过 REST API 创建和配置环境。 有关详细信息,请参阅“适用于部署环境的 REST API 终结点”、“GitHub Actions 机密的 REST API 终结点”、“GitHub Actions 变量的 REST API 终结点”和“适用于部署分支策略的 REST API 终结点”。

运行引用不存在的环境的工作流程将使用引用的名称创建环境。 新创建的环境将不配置任何保护规则或机密。 可在仓库中编辑工作流程的任何人都可以通过工作流程文件创建环境,但只有仓库管理员才能配置环境。

使用环境

工作流程中的每个作业都可以引用单个环境。 在将引用环境的作业发送到运行器之前,必须通过为环境配置的任何保护规则。 只有在将作业发送给运行器后,作业才能访问环境的机密。

当工作流程引用环境时,环境将显示在仓库的部署中。 有关查看当前和以前的部署的详细信息,请参阅“查看部署历史记录”。

可以为工作流中的每个作业指定环境。 为此,请添加一个 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 将显示在存储库的部署页(通过单击存储库主页上的“环境”进行访问)和工作流运行的可视化图中。 如果拉取请求触发了工作流,则 URL 还会在拉取请求时间线中显示为“查看部署”按钮。

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

删除环境

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

删除环境将删除与环境关联的所有机密和保护规则。 由于已删除环境的保护规则而正在等待的任何作业将自动失败。

  1. 在 GitHub.com 上,导航到存储库的主页。

  2. 在存储库名称下,单击 “设置”。 如果看不到“设置”选项卡,请选择“”下拉菜单,然后单击“设置”********。

    存储库标头的屏幕截图,其中显示了选项卡。 “设置”选项卡以深橙色边框突出显示。

  3. 在左侧边栏中,单击“环境”。

  4. 在要删除的环境旁边,单击

  5. 单击“我了解,删除此环境”。

您也可以通过 RESEST API 删除环境。 有关详细信息,请参阅“存储库的 REST API 终结点”。

环境与部署的关系

当引用环境的工作流作业运行时,它将创建一个部署对象并将 environment 属性设置为环境名称。 随着工作流的进行,它还将创建部署状态对象,并将 environment 属性设置为环境名称,将 environment_url 属性设置为环境的 URL(如果在工作流中指定),以及将 state 属性设置为作业的状态。

您可以通过 REST API 或 GraphQL API 访问这些对象。 您还可以订阅这些 web 挂钩事件。 有关详细信息,请参阅“存储库的 REST API 终结点”、“对象”(GraphQL API) 或”Webhook 事件和有效负载”。

后续步骤

GitHub Actions 具有多个用于管理部署的功能。 有关详细信息,请参阅“使用 GitHub Actions 进行部署”。