CI/CD 是什么？先聊聊我的理解
经常有人问我：“CI/CD 不就是跑个自动化脚本吗？” 说实话，我第一次接触时也这么想。
直到我参与了一个传统瀑布式开发的项目。那时候，开发团队写了三个月代码，最后花了两周手工合并——结果呢？编译不过、测试全挂、部署更是噩梦。那次经历让我彻底明白，没有 CI/CD，所谓的“敏捷”只是口号。
CI/CD 全称是 持续集成（Continuous Integration）、持续交付（Continuous Delivery） 和 持续部署（Continuous Deployment）。它们不是三个独立工具，而是一套自动化的软件交付理念。核心目标只有一个：让每一次代码变更都能快速、安全地到达用户手中。
持续集成：每天合并几十次，你敢吗？
持续集成要求开发者频繁地将代码合并到主干，至少每天一次。合并后自动触发编译和自动化测试，即时反馈结果。
我个人习惯是每次提交前先本地跑一遍单元测试和 lint，确保“绿了”再 push。但即使这样，集成时照样可能出问题。为什么？因为别人的代码改了公共接口。这也是为什么 CI 服务器要自动跑测试，而不是靠人的自觉。
持续交付 & 持续部署：一键发布不是梦
持续交付是在 CI 的基础上，保证代码 随时可以部署到生产环境。区别在于，部署操作需要人工点击确认。
持续部署则更激进——所有通过自动化测试的变更会自动发布到生产。我曾在电商项目中用过持续部署，双十一前的紧急修复，从提交到上线平均只需要 12 分钟。你想想看，手工操作根本做不到这个速度。
| 维度 | 传统开发 | CI/CD |
|---|---|---|
| 集成频率 | 每周/每月 | 每天多次 |
| 反馈周期 | 数天甚至数周 | 分钟级 |
| 部署风险 | 高（大版本一次性发布） | 低（小步快跑，易回滚） |
| 自动化程度 | 手工为主 | 全流程自动化 |
| 团队协作 | 各自为战 | 共享责任、快速对齐 |
CI/CD 的核心价值——用数据说话
别光听我吹。我记得某次技术分享会上，一个团队展示了他们的 CI/CD 收益：
- 发布周期从 2 周缩短到 2 小时——但不是所有项目都需要这么激进，关键是缩短等待时间。
- 缺陷逃逸率降低 70%——因为每一次提交都跑全量自动化测试，很多低级 bug 在集成阶段就拦住了。
- 新功能上线风险可控——灰度发布 + 自动回滚，即使用户反馈不好，也能立刻切回去。
重要发现：CI/CD 最大的价值不是“自动化”，而是降低“人类决策的摩擦”。当你不用纠结“要不要合并”、“会不会冲突”、“部署后会不会挂”时，开发人员才能真正聚焦在业务逻辑上。
CI/CD 流程长什么样？
下面这张图是我平时画给团队看的。它展示了从代码提交到生产部署的典型流水线。注意，每经过一个环节，制品都会变得更“可靠”。
一次真实的“溜号”教训
我曾经在一个早期项目中过于自信，认为“小改动不用跑 CI”，直接合并到 master 之后才发现破坏了另一个模块的 API 兼容性。修复花了半天，连带影响三个子团队。打那以后，我定了一条铁规：任何改动，哪怕只改了一行注释，也必须经过 CI 验证。你可能会觉得夸张，但你想想看，注释里的字符串变了，也可能导致文档生成工具报错。
总结一下
CI/CD 不仅仅是一堆 yaml 文件和 Jenkins 任务。它背后代表的是一种“信任模型”：你信任自动化流程能尽早发现问题，因此你可以更放心地提交代码。反过来，自动化也约束了你——不能偷懒、不能跳过、不能“先试试看”。
这本教程会从 Mock 回放的角度切入，带你亲手搭建一条具备“回放测试”能力的 CI 流水线。但不管你用哪种工具，理解今天说的这些核心价值，才是后续所有实践的前提。