GitHub Actions environments怎样给部署环境设置审批门槛

如果生产部署不能由每次提交自动直达，GitHub Actions 的 environments 可以把“是否允许继续”交给指定人员确认。做法是创建一个名为 production 的环境，打开 Required reviewers，再让部署 job 引用这个环境。运行到该 job 时，页面会显示 Waiting，审查者可以选择批准或拒绝。

官方地址：https://docs.github.com/en/actions/how-tos/deploy/configure-and-manage-deployments/control-deployments

下面按 GitHub 网页中的入口顺序说明。文中的界面图是原创操作示意图，不是 GitHub 实际截图；workflow 片段用于展示配置关系，不代表已经在本机运行。

先确定审批应该卡在哪个 job

环境审批保护的是“引用该环境的 job”，不是整个 workflow 文件。通常把它放在构建和测试完成之后的部署 job 上：前面的检查先跑完，真正会接触生产资源的 job 再等待人工决定。

例如，build 负责准备产物，deploy-production 负责发布。只有后者写上 environment: production，production 环境的保护规则才会介入。环境规则通过前，环境中保存的 secrets 也不会提供给该 job。

创建 production 环境并打开保护规则

1. 打开目标仓库，进入 Settings。
2. 在左侧找到 Environments，选择 New environment。
3. 输入环境名 production 并创建。
4. 在该环境的 Environment protection rules 区域找到 Required reviewers。
5. 添加负责审核发布的用户或团队；如果不希望发起者批准自己的部署，同时打开 Prevent self-review。
6. 点击 Save protection rules 保存。

继续条件：环境名称是 production，审查者已经出现在规则列表中，并且保存按钮完成了设置。不要把个人令牌、云平台密钥或真实仓库信息放进说明图或示例文件。

Required reviewers 应该怎样选择

审查者可以是用户或团队，配置时优先选择真正能判断发布风险的人。一个团队多人时，流程重点是“由被列出的审查者完成确认”，而不是让所有成员逐个点击。GitHub 文档还说明，必需审查者规则最多可列出六个用户或团队，审查者至少需要对仓库有读取权限。

Prevent self-review 适合把提交者和审批者分开：发布由甲发起，乙确认后继续。若团队明确允许同一人自查自发，可以不打开它，但这会削弱审批门槛的独立性。

环境还可以配置分支限制、等待计时器或其它部署保护规则。本文只讨论人工审查；不要把等待计时器误认为审查，它只会延迟作业，并不会替代某个具体人员的批准。

让部署 job 引用 production 环境

环境创建好之后，workflow 需要在部署 job 上写出同名的 environment。名称必须与网页里创建的环境完全一致，大小写和空格也要保持一致。

name: deploy

on:
  push:
    branches: [main] # 只让主分支的变更进入这个示例流程

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4 # 拉取仓库内容，供后续构建使用
      - name: 构建发布产物
        run: npm run build # 示例命令，替换成项目自己的构建命令

  deploy-production:
    needs: build # 构建成功后才进入部署 job
    runs-on: ubuntu-latest
    environment:
      name: production # 绑定网页中创建的受保护环境
    steps:
      - name: 发布到生产环境
        run: ./scripts/deploy.sh # 审批通过后才会执行发布动作

这里的关键不是 name 字段本身，而是 job 级别的 environment.name。当 deploy-production 走到环境规则时，作业会暂停；审批通过后才继续执行后面的发布步骤，并按环境规则提供相应 secrets。

在 Actions 运行页找到 Waiting 状态

1. 打开仓库的 Actions，进入刚刚触发的 workflow run。
2. 找到 deploy-production job；如果它已到达受保护环境，状态会显示为 Waiting 或待处理。
3. 在部署保护区域点击 Review deployments。
4. 选中 production，阅读本次变更说明或关联的检查结果。
5. 确认发布时点击 Approve and deploy；不允许发布时点击 Reject。

批准后，job 才会继续执行部署步骤；拒绝则会使这次 workflow 失败。若环境开启了禁止自审，发起该 workflow 的用户即使出现在审查者列表里，也不能批准自己的部署。

审批门槛不生效时先查这五项

一份可以保存的配置清单

• 网页设置：存在 production 环境，并已保存 Required reviewers。
• workflow 绑定：部署 job 使用 environment.name: production，不是只在 workflow 名称里写 production。
• 审批职责：审查者有读取权限，且团队已决定是否禁止发起者自审。
• 运行验收：Actions 页面能看到 Waiting、Review deployments，批准后 job 才进入发布步骤。
• 边界意识：等待计时器、分支限制和自定义保护规则是不同机制，不能用其中一个的表现推断另一个已经生效。

如果你的目标只是把生产密钥集中管理，环境也可以承担配置组织和访问控制；如果目标是“每次生产发布必须有人点确认”，则至少要同时完成 Required reviewers 设置和部署 job 的环境绑定。

相关问题

Required reviewers 是给整个 workflow 加审批吗？

不是。它作用于引用该环境的 job。把环境绑定到生产部署 job，通常比把所有检查都放进一个受保护 job 更容易看清审批发生在哪个阶段。

一个审查者团队需要所有人都批准吗？

审批配置的重点是列出允许审查的用户或团队；实际采用哪种团队内部批准规则，还要结合组织权限和发布制度。文章中的界面示意只表示配置入口，不替团队制定内部流程。

为什么批准后环境 secrets 才能使用？

这是环境保护的安全边界。关联 job 在规则通过前不能访问该环境的 secrets，避免未经人工确认的工作流先拿到生产凭据。