一、CI/CD 到底是什么？我为什么觉得它值一套课？

先问一个直白的问题：你每天花多少时间在“让代码跑起来”这件事上？我见过不少团队，开发半天，部署两天。代码写好了，却卡在整合、测试、发布这些环节上。说白了，CI/CD 就是把这些重复劳动自动化掉。

我个人习惯把 CI/CD 理解成“流水线”——你只管提交代码，剩下的事让工具去完成。但这不只是省时间这么简单。我在项目里踩过很多坑，比如一次合并冲突直接让整个版本延期两周。后来才明白，真正的价值是让团队能快速、安全地交付。

1.1 持续集成（CI）——别让代码“攒”着

持续集成，核心就是频繁地把代码合并到主干。有多频繁？我建议每天至少一次。你不会想把一周的工作量攒到周五下午一次性提交——那简直是噩梦。

举个例子：我们之前有个微服务项目，20多人同时开发。如果不做 CI，每次合并就像开盲盒。后来上了 Jenkins 跑流水线，每次提交自动编译+跑 2000 多个单元测试。碰见失败立刻通知，问题根本过不了夜。

1.2 持续交付（CD）——随时准备上线

持续交付的意思，是让你的代码每次都能安全地部署到生产环境。这不代表你每次都要发布，而是说你随时可以发布。我记得有一回客户突然要求第二天早上上线一个紧急功能，我们因为有完整的 CD 流水线，直接合并分支、跑完自动测试、滚动部署，半小时搞定。要不是有这套东西，凌晨三点还在人工操作。

维度	没有 CD	有 CD
部署频率	月/季度	周/天
发布风险	高（一步到位）	低（小批量灰度）
回滚速度	小时级	分钟级
团队士气	怕发版	想发就发

1.3 持续部署——更极致的自动化

持续部署是在持续交付之上再加一把火：全部自动化。没有人工点击“确认上线”这个按钮。什么情况适合？测试覆盖率极高、灰度机制成熟、监控体系完善。我不建议新手团队一上来就搞持续部署。先跑通持续交付，有足够的自信再说。

1.4 核心流程长什么样？

下面这张图是我自己整理的一套标准流程，你一看就明白。其实每家公司的流水线细节不一样，但骨架差不多。

1.5 常用工具怎么选？

工具这东西，没有最好只有最合适。我统计了几个主流选手的对比，你挑的时候可以参考。

工具	类型	适合场景	我踩过的坑
Jenkins	自托管	高度定制、插件丰富	插件升级容易炸，建议锁版本
GitLab CI	SaaS / 自托管	GitLab 生态用户	跑大量并行 job 时注意 Runner 资源
GitHub Actions	SaaS	开源项目、中小团队	免费额度用起来很快，得规划
CircleCI	SaaS	速度优先的团队	缓存机制坑多，要仔细调
ArgoCD	Kubernetes 原生	K8s 部署 GitOps	学习曲线略陡，但值得

1.6 为什么把 CI/CD 放在第一章？

嗯，这个问题我问过自己很多次。因为后面的 29 章，每章都是建立在“自动化交付”这个信念上的。如果你不信 CI/CD 能带来实际价值，后面那些配置、优化、安全加固你根本坚持不下去。

我记得有个初创公司，团队 8 个人，起初觉得“我们项目小，手动部署就行”。结果三个月后，代码库从 2 万行涨到 20 万行，手动部署一次要 4 个小时，还总出错。后来我帮他们搭了一套极简流水线，30 分钟搞定整个流程。老板当场说：“早该弄的。”其实不早不晚，意识到问题就是最好的时机。

说实话，CI/CD 最大的好处不是省时间，而是让你敢于修改代码。因为你心里有底：就算改坏了，流水线会拦着，会回滚。这种安全感，才是团队从“怕改动”进化到“快迭代”的基石。