环境晋级是什么
同一制品按 dev、staging、prod 逐级晋级：每一级记录部署结果，追溯到谁把哪个版本、在什么时候部署到了哪个环境；敏感环境用审批与保护规则控制。晋级的是同一制品与镜像，只有配置与批准层级变化，验证结果才能从预发迁移到生产，回滚也才有共同基准。
基本信息
| GitLab | environment 名称加部署记录，页面可追溯部署内容 |
|---|---|
| GitHub | environments 绑定保护规则：必需审批人与允许分支 |
| 原则 | 制品不变，只有配置与批准层级变化 |
| 命名 | 环境名保持稳定，不带随机后缀 |
| 凭据 | 各环境凭据独立，事故污染半径可控 |
典型使用场景
- 多环境流程：开发自测后推荐到预发，再审批上生产。
- 部署审计：部署页面回溯版本与操作者。
- 审批门：生产环境需指定审批人通过后才执行。
- 受限分支：生产部署仅允许从主分支发起。
- 等待机制：审批未通过时保持等待，而不是超时失败。
- 回滚同路：回滚也走同一套环境与记录体系。
GitLab 晋级示例
GitLab 晋级示例
deploy-staging:
environment: staging
script: ./ci/deploy.sh staging
deploy-prod:
environment: production
when: manual
script: ./ci/deploy.sh prod环境阶梯
| 环境 | 门槛 | 目标 |
|---|---|---|
| dev | 自动 | 快速验证合理性 |
| staging | 自动或轻审批 | 接近生产的完整验证 |
| production | 审批与保护规则 | 承载真实用户流量 |
环境名保持稳定，不要带随机后缀，否则部署历史碎片化无法聚合。
晋级失败要能重试：环境级重跑入口保持可用，卡在某一级时不必重新编制品。
预发与生产要尽量同构：配置差异越大，晋级到生产暴露的问题越多。
晋级检查清单挂在环境上：冒烟结果、指标窗口、变更单号，条件满足后审批才有依据。
发布记录与代码版本双链：从部署记录能跳回提交，事后复盘时直接对照。
审批后接自动冒烟：通过审批先跑冒烟作业再放量，比全程人工更省时间。