GitHub Environments 是什么
为部署目标建模环境：配置必需审批人、等待计时器与允许部署的分支，密钥与变量挂在环境上按需可见。环境是部署治理的落点：生产环境加审批与分支限制后，只有满足规则的作业才能拿到生产密钥；同一仓库可以建 staging、production 等多个环境，各自复用同一套保护策略。
基本信息
| 保护规则 | Required reviewers（人工批准）、Wait timer（延迟放行）、Deployment branches（限定分支） |
|---|---|
| 作用域 | environment secrets/variables 仅在该环境作业可见 |
| 审批超时 | 等待超时按规则取消或保持等待，按平台设定核对 |
| 命名 | 先约定环境命名（staging、production），规则按环境配置 |
| 粒度 | 按环境授权密钥，构建作业拿不到生产密钥 |
典型使用场景
- 生产部署：绑定 production 环境，人工审批后放行
- 预发部署：环境无审批或轻审批，快速迭代
- 密钥隔离：不同环境各自密钥，互不可见
- 发布冻结：等待计时器强制冷却窗口
- 分支限制：只允许 main 或标签部署生产
- 部署审计：部署记录与审批人留痕
实践要点
- 命名先行：prod 与 production 混用会让规则与密钥分散
- 审批独立：审批人不要包含触发者本人与机器人
- 最小密钥：环境内密钥按作业需要下发
- 文档化：每个环境的规则与责任人写进仓库文档
- 复核周期：季度检查审批人与分支限制是否仍合适
- 分级审批：预发轻、生产重，按环境影响面配置规则
作业绑定环境
作业绑定环境
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- run: ./ci/deploy.sh保护规则
| 规则 | 作用 | 注意 |
|---|---|---|
| Required reviewers | 人工批准部署 | 审批人独立 |
| Wait timer | 延迟放行 | 给回滚留窗口 |
| Deployment branches | 限定可部署来源 | 与保护分支一致 |
同一仓库多个环境可复用自己的保护策略：先约定命名（staging、production）。
环境是密钥的隔离边界：把生产密钥放生产环境，构建阶段自然拿不到。