GitHub Actions 怎样为生产环境增加审批

如果生产部署不能直接执行，希望有人确认后再继续，GitHub Actions 的做法是把部署 job 绑定到一个配置了 Required reviewers 的 production environment。工作流运行到这个 job 时会先等待环境保护规则；审批通过后，job 才会被送到 runner 执行。

官方地址：https://github.com/

对应文档：https://docs.github.com/en/actions/concepts/workflows-and-actions/deployment-environments

第1步：打开 production 环境配置入口

进入目标仓库，打开 Settings > Environments。选择已有的 production，如果还没有就创建一个同名环境。环境名称后面会原样写进 workflow，因此建议使用简单、稳定且不会频繁改名的 production。

进入环境详情后，先找到 Deployment protection rules 和 Deployment branches and tags 两块区域。前者决定部署是否需要额外条件，后者决定哪些分支可以进入这个环境。

第2步：添加必需审批人

在 Deployment protection rules 中启用 Required reviewers，添加负责生产发布的用户或团队。审批人不需要参与每一个提交，但必须具备能够审查并批准该仓库部署的权限。

如果要求发起部署的人不能自己批准，可以同时打开 Prevent self-review。这个选项适合把“提交代码”和“生产放行”分开，减少一个人从触发到上线的单人闭环。

保存后，production 环境会保留这条规则。注意，Required reviewers 是环境级设置，不是某个 pull request 的临时评论；以后所有引用该环境的 job 都会遵守它。

第3步：限制可部署分支

继续看 Deployment branches and tags。如果只有受保护的生产分支才能发布，可以选择 Protected branches；如果规则更细，可以使用自定义分支策略，只允许例如 main 或 release/** 进入 production。

分支策略和审批是两道不同的门：分支策略先限制“谁能尝试进入环境”，Required reviewers 再决定“这次尝试是否放行”。不要只配置审批而完全忽略触发分支，否则测试分支也可能不断产生生产审批请求。

第4步：让部署 job 引用 production 环境

打开仓库中的 workflow 文件，把生产部署步骤放进一个单独的 job，并在 job 层级加入 environment: production。下面是最小结构，注释说明每个关键位置：

name: deploy

on:
  push:
    branches: [main] # 只让生产分支触发这条部署工作流

jobs:
  deploy-production:
    runs-on: ubuntu-latest # 审批通过后才会申请这个 runner
    environment:
      name: production # 必须与仓库中的环境名称完全一致
      url: https://example.com/ # 可选：在部署记录中显示生产地址
    steps:
      - uses: actions/checkout@v4 # 取出待发布的提交
      - name: Deploy
        run: ./scripts/deploy.sh # 只有环境规则通过后才执行生产命令

这里最容易写错的是缩进和层级：environment 要和 runs-on、steps 同属于 deploy-production，不能把它写成某个 step 的普通参数。url 是可选的，若不需要在部署记录中展示地址可以删除。

如果生产凭据存放在 environment secrets 中，job 也必须正确引用该 environment。GitHub 文档说明，环境保护规则通过前，job 不会访问该环境的 secrets。

第5步：审核并处理不生效情况

提交 workflow 后，打开仓库的 Actions，进入对应的工作流运行记录。当流程走到 deploy-production 时，应该看到类似 Review required 的等待状态。打开 Review deployments，选择 production，按需要填写说明，然后点击 Approve and deploy；不接受本次上线则选择拒绝。

如果没有出现审批，按下面顺序检查：

1. 确认 job 写的是 environment: production，名称大小写和仓库环境完全一致。
2. 确认 Required reviewers 保存于当前仓库的 production 环境，而不是另一个同名相似环境。
3. 确认触发分支满足 Deployment branches and tags；规则不匹配时，问题不是审批按钮消失，而是环境分支策略先拒绝了部署。
4. 确认查看工作流运行的人具备审批权限，并且没有把部署命令放在另一个未绑定环境的 job 中。

常见问题

只创建 production 环境，为什么没有审批？

环境本身不会自动产生审批。必须在环境中添加 Required reviewers，并在实际部署 job 上引用这个环境。

审批前能读取 production secrets 吗？

不能。正确的 job 会在环境保护规则通过后才获得该环境 secrets；不要把同一凭据复制到仓库级 secrets 来绕开这道门。

为什么审批后 job 仍然没有运行？

先看分支策略、并发设置和 runner 可用性。审批只表示环境规则已通过，不代表分支限制、队列或 runner 资源一定同时满足。

最终可以用四项结果判断配置是否完成：production 环境存在 Required reviewers，生产分支满足部署策略，部署 job 明确写有 environment: production，工作流运行页在执行生产步骤前出现 Review required。满足这些条件后，生产上线就从“提交即执行”变成“触发后等待明确放行”。