gitlab ci回滚应在部署后健康检查失败时触发，而非构建失败时；需持久化记录上一健康版本（如commit sha或镜像tag）；回滚作业须满足自动调用、权限完备、操作幂等；回滚后须二次验证并通知审计。
GitLab CI 实现构建失败的自动化回滚，核心不是“一失败就回滚”，而是**在部署后验证失败时，自动恢复至上一个已知健康版本**。构建阶段（如编译、单元测试）失败通常不该触发回滚——它还没影响生产环境；真正需要回滚的是已成功部署但健康检查失败的生产发布。
明确回滚触发点：部署后验证失败才启动
回滚动作必须绑定在部署完成后的验证环节，而非编译或测试失败时。否则会把开发问题误当生产事故处理，造成混乱。
- ✅ 正确路径：deploy → wait → health-check（如调用 /health 端点、跑冒烟测试、查监控指标）→ 若失败 → 自动触发 rollback-job
- ❌ 错误做法：build 或 unit-test 失败就执行回滚脚本——此时代码根本没上线，无需回滚，只需修复并重试流水线
关键前提：可靠记录上一个健康版本
没有版本锚点，回滚就是无源之水。必须在每次成功部署到生产环境时，持久化记录该版本标识。
- 用 Git Commit SHA：在 deploy 作业末尾写入
echo "DEPLOYED_VERSION=$CI_COMMIT_SHA" > version.env，再用artifacts: [version.env]保存供后续作业读取 - 用 Docker 镜像 Tag：若容器化部署，将
registry.example.com/app:${CI_COMMIT_SHORT_SHA}作为部署镜像，并通过 API 或配置中心同步该 Tag 到 rollback-job - 避免硬编码或人工维护：不依赖“上一次提交”这种模糊概念，而用明确、可追溯、带时间戳的标识
配置可触发的回滚作业
回滚作业需满足三个条件：可被自动调用、具备执行权限、操作原子安全。
- 定义为独立 job，stage 设为
rollback，并用rules控制仅在验证失败时运行：rules:<br> - if: $HEALTH_CHECK_STATUS == "failed"<br> when: always
- 使用幂等操作：Kubernetes 场景下用
kubectl rollout undo deployment/app --to-revision=xxx；传统服务器用软链接切换（ln -sf v1.2.0 /opt/app/current） - 禁止
git reset --hard直接改生产分支：应使用git revert生成新提交，或通过部署系统（如 Argo CD、GitOps 工具）同步声明式状态
增强可靠性：验证 + 通知 + 审计缺一不可
回滚不是终点，而是故障响应闭环的一环。
- 回滚后必须再次执行健康检查，确认服务已恢复；失败则标记 pipeline 为 “rollback failed”，阻断后续流程
- 通过 Slack、邮件或 GitLab Notification 发送结构化消息：“生产环境已回滚至 v2.1.4（SHA: a1b2c3d），MTTR = 58s，原始失败原因：5xx 错误率突增至 92%”
- 所有回滚操作日志、前后版本快照、验证结果自动存档到对象存储，满足审计与复盘需求
