我配了三年 GitHub Actions，今天才把 Environment Protection Rules 这套组合拳的账全算清楚了——生产部署不只是配个 Secrets，还有四层防护是你可能从来没配到位的

生产环境部署最怕什么？不是代码有 bug，是「谁都能部署上去」。

GitHub Actions 的 Environment Protection Rules 就是这道门的四把锁。

第一层：Required Reviewers

指定用户或团队审批后才能继续。最多列 6 个账号，任意 1 人通过即可继续。适合生产环境，运维或 tech lead 必须点同意才能跑。配置路径：Settings → Environments → 选择环境 → Required reviewers。

第二层：Wait Timer

触发后强制等待，最长 30 天。适合发布窗口控制，比如「每周三下午才能发布」——Wait Timer 设 0 分钟但配合 CI 时段限制，或者「发布前至少等 30 分钟观察」——Wait Timer 设 30 分钟。紧急修复时可以用 workflow_dispatch 临时跳过。

第三层：Deployment Branch Policy

只有特定分支能部署到该环境。比如只允许 release/* 或 production 分支触发，保护网不被人为错误触发。比如有人从 feature/fix-bug 推了个同名分支，Deployment Branch Policy 直接把它拦在门外。

第四层：Environment Secrets

环境级密钥。Job 必须通过所有保护规则后才能访问这些密钥。这意味着你的生产数据库密码、API Key 只有经过 Required Reviewers 审批的 job 才能读到，其他 job 跑完也读不到。

四层叠加的正确姿势

常见错误：配了 Required Reviewers 但没配 Environment Secrets——审批流过了，但密钥还是被未审批的 job 访问了。正确做法：Environment Secrets 和 Required Reviewers 一起配，这样审批通过后 job 才能读取密钥。

jobs:
  deploy:
    environment:
      name: production
      url: https://app.example.com
    # 这里隐式要求 Required Reviewers 通过 + Wait Timer 结束 + 分支合规
    steps:
      - run: npm run deploy
        env:
          DATABASE_URL: ${{ secrets.DATABASE_URL }}  # 只有通过保护规则才能读到

踩过的坑

1. Required Reviewers 配了但成员都有 admin 权限——admin 可以跳过审批，Environment Protection Rules 对 admin 账号无效
2. Wait Timer 在紧急修复时成为瓶颈——用 workflow_dispatch 配合环境变量临时绕过，或者单独建一个「紧急发布」环境，Wait Timer 设为 0
3. 分支策略只配了 branch name 但忘了 tag——发布时打的是 tag 不是 branch，Deployment Branch Policy 只认分支名，tag 触发会直接失败

下一步怎么走？

如果你现在只有一个 production environment，建议拆成两个：production（Required Reviewers + Wait Timer 30分钟 + 分支策略）和 production-urgent（只有 Required Reviewers，Wait Timer 0）。日常发布走前者，紧急修复走后者——后者仍然需要人工审批，但不需要等 30 分钟。

GitHub Actions 环境保护的文档在 docs.github.com/en/actions/deployment/targeting-different-environments，每个企业级项目都应该把这四层锁配上。