CI/CD 与发布回滚
0. 引言
CI/CD 的目标不是"把部署自动化"这么简单，而是让代码从提交到上线的链路可重复、可审计、可回退。上线失败时，真正决定团队恢复能力的，不是"会不会发版"，而是"能不能快速回到稳定版本"。本章先梳理一条最基础的交付链路，再按构建、制品、发布三阶段给出 Java 项目的常见实践，最后聚焦回滚设计与发布策略选型。
1. 概念辨析
- CI（持续集成）：频繁合并、自动构建、自动测试——让集成问题尽早暴露；
- CD（持续交付/部署）：让版本稳定地流向测试与生产环境——交付/部署自动化。
2. 一条最基础的交付链路
- 开发提交代码；
- 触发流水线；
- 编译、单元测试、静态检查；
- 构建产物或镜像；
- 发布到测试环境；
- 验证通过后进入生产发布；
- 监控指标与日志观察；
- 异常时快速回滚。
图表渲染中…
3. Java 项目的三阶段实践
3.1 构建阶段
- 使用 Maven 或 Gradle 统一构建，测试、格式检查、依赖漏洞扫描纳入流水线；
- 构建产物保持唯一版本号，避免"同名不同包"。
3.2 制品阶段
- Jar 包或 Docker 镜像可追溯到具体提交（镜像标签含 commit 号）；
- 镜像构建优先多阶段构建，缩小体积；
- 发布不依赖服务器现场编译——制品应提前构建完毕。
3.3 发布阶段
- 测试环境与生产环境分离；
- 配置外置，通过环境变量或配置中心注入；
- 数据库变更与服务发布做顺序控制——先兼容后切换，避免新旧代码与新旧表结构不匹配。
4. 回滚为什么重要
上线失败时，回滚能力决定恢复速度。常见回滚方式：
| 方式 | 说明 |
|---|---|
| 重新部署上一版本镜像 | 最直接，前提是制品可追溯 |
| 切换流量回旧实例 | 蓝绿/灰度架构下的秒级切流 |
| 灰度失败中止扩散 | 中止放量，保留已观察数据 |
| 配置变更版本化管理 | 配置回滚与应用回滚协同 |
5. 发布策略选型
| 策略 | 机制 | 优点 | 注意 |
|---|---|---|---|
| 蓝绿发布 | 新旧两套环境并存 | 切流后快速切回 | 资源成本更高 |
| 金丝雀发布 | 少量流量先进新版本 | 观察真实流量下的异常率与延迟 | 需要流量切分能力 |
| 滚动发布 | 逐步替换旧实例 | 资源占用低 | 没有健康检查与监控时回滚麻烦 |
6. 常见误区
- 只有自动部署，没有自动验证：发布后不检查健康状态，等于把验证留给人肉；
- 生产回滚靠人工 SSH 改命令：回滚必须和发布一样自动化、可重复；
- 数据库变更不可回退，却把应用发布当可逆操作：数据库变更要有向前兼容设计；
- 流水线只关注构建成功：构建绿不代表发布后健康，监控与告警必须接入流水线闭环。
7. 小结
- CI/CD 本质：可重复、可审计、可回退的交付链路，而非单纯的自动化脚本；
- 三阶段要点：唯一版本号、制品可追溯、配置外置、DB 变更与控制权分离；
- 回滚设计要提前做：真正出故障时没有时间现想方案；
- 发布策略：蓝绿重成本保速度、金丝雀控风险、滚动省资源，按变更风险选择；
- 核心思维：很多事故不是代码错，而是变更顺序错——发布与数据库变更必须协同编排。
下一章讲解前端自动化与 CI/CD 概念——前端项目如何接入持续集成流水线。