environment 与部署跟踪是什么
在 GitLab CI 中声明作业对应的部署环境：GitLab 会记录每次部署的版本、时间与操作人，支持环境级停止、部署历史查看与受保护环境审批。评审环境使用随分支变化的动态名称批量创建，配合停止作业用完即清。这些记录是发布审计与回滚定位的基础数据，也是「谁在何时把哪个版本部署到哪」的答案。没有声明环境的部署作业不会出现在环境页面，部署记录也就缺失，事后无法追溯。
基本信息
| 写法 | environment 下声明 name 与 url |
|---|---|
| 动态名 | 评审环境用分支标识派生的动态名称 |
| 停止 | on_stop 关联停止作业回收环境 |
| 治理 | 受保护环境可要求审批后才允许部署 |
| 记录 | 每次部署的版本、时间与提交可查 |
| 停止语义 | action: stop 标记该作业用于回收环境 |
| 取名建议 | 名称稳定可读，动态名要能回溯到分支 |
部署与停止作业
部署与停止作业
deploy-staging:
stage: deploy
script: [./deploy.sh staging]
environment:
name: staging
url: https://staging.example.com
# 评审环境：动态名 + 停止作业
stop-review:
stage: deploy
when: manual
script: [./teardown.sh]
environment:
name: review/$CI_COMMIT_REF_SLUG
action: stop能力对照
| 能力 | 配置 | 效果 |
|---|---|---|
| 部署记录 | environment.name | 版本与时间写入历史 |
| 评审环境 | 动态 name | 每个分支一套环境 |
| 环境回收 | action: stop | 手动或自动清理 |
| 上线审批 | 受保护环境设置 | 部署前需要批准 |
典型使用场景
- 固定环境（测试、预发）：名称稳定，部署历史集中可查
- 评审环境：按分支动态创建，评审结束手动或自动清理
- 受保护环境：生产部署要求审批，防止误操作直接上线
- 回滚定位：通过部署历史找到上一个正常版本及其提交
- 发布审计：回答谁在何时把哪个版本部署到哪个环境
- 多环境链路：测试、预发、生产各自声明环境，形成从构建到上线的完整部署轨迹
环境记录让「谁在什么时候把哪个版本部署到哪」可查，是发布审计的基座。环境页同时提供重新部署与回滚入口，与版本记录配合使用。
停止作业可以设为手动触发或随分支合并自动执行，按团队清理节奏选择。环境页同时提供重新部署与回滚入口，与版本记录配合使用。