1. Environment：把「部署到哪儿」写进平台，而不是写进口头约定
在仓库 Settings → Environments 创建 development、staging、production 等环境。 在 job 上声明 environment: production 后，该 job 的部署会关联到该环境的保护规则与环境密钥。
与合并门禁的区别：分支保护解决「代码能否进 main」；Environment 解决「进了 main 之后能否触发生产部署」——两者应叠加使用。
图 1：环境晋级。每一格是 GitHub Environment；中间的 gate 对应审批、定时器或分支策略。
2. Protection rules：谁能部署、从哪条分支部署
常见规则包括：Required reviewers（人工审批）、Wait timer（冷却时间）、 Deployment branches（仅允许 main / release/* 触发生产）。 规则与组织合规策略对齐：生产越敏感，门槛越高。
图 2：生产环境典型「三件套」：人（审批）、时间（等待）、来源（分支/tag 策略）。
3. 在 workflow 里绑定 environment
在 job 级别设置 environment:，可写 name 与可选 url（部署结果链接）。 生产 job 应单独一个 job，便于与构建/测试分离，并在环境上挂密钥。
jobs:
deploy-prod:
runs-on: ubuntu-latest
environment:
name: production
url: https://app.example.com
steps:
- uses: actions/checkout@v4
- name: Deploy
run: ./deploy.sh
4. 环境密钥与「最小可见」
在 Environment 下配置 secrets，仅对绑定到该 environment 的 job可见，比仓库级 secrets 更细。 结合 OIDC（第 35 章）可把云访问也做成短期凭证，减少长期密钥。
图 3：部署 job 声明 environment 后，才进入该环境的审批链与密钥可见范围。
5. 与 concurrency、rollback 的衔接
对同一环境使用 concurrency 可避免并行部署踩脚（例如 group: prod-deploy + cancel-in-progress）。 回滚策略：重新部署上一版本、或蓝绿/金丝雀（实现落在应用与基础设施层，流水线负责触发与验证）。
图 4：部署与审批记录进入审计视图；事故复盘与合规检查依赖「谁在何时部署了什么」。
6. 最小清单
- 为 dev/staging/prod 建 Environment；生产必须配置 protection（审批/分支/等待）。
- 生产密钥放 environment secrets；部署 job 单独拆分并绑定 environment。
- 合并门禁（分支保护）与部署门禁（Environment）分层设计，不混为一谈。
- 结合 concurrency 防止并行部署；保留部署历史便于回滚与审计。