1. CI/CD概述：什么是持续集成、持续交付与持续部署，为什么需要CI/CD，CI/CD的核心价值与收益

大家好，我是你们这门课的老朋友。今天咱们来聊聊CI/CD。

说实话，我刚开始做开发那会儿，根本不知道什么叫CI/CD。代码写完了，往测试环境一扔，跑一下，没问题就上线。听起来挺简单是吧？但实际体验过你就知道，那简直是噩梦。

有一次，我负责一个电商项目。团队十几个人，各自开发各自的功能。到了周五下午，大家开始往主干合并代码。好家伙，冲突一个接一个，修完冲突编译又报错，编译过了测试又挂了。最后搞到凌晨两点，才勉强把版本发出去。第二天线上出了个bug，回滚又花了半小时。

嗯，从那以后，我就开始认真研究CI/CD了。

什么是持续集成？

持续集成，说白了就是「频繁地把代码合并到主干」。我个人习惯是每天至少合并一次。

你可能会问：「频繁合并有什么用？」

我举个例子。假设你和同事各自开发一个模块，你们俩两周没合并。等到最后一天，你发现他改了你的接口，他改了你的数据结构。这时候再合并，冲突能让你改到怀疑人生。

但如果你们每天合并一次呢？冲突最多就是几行代码的事，几分钟就搞定了。

持续集成的核心流程是这样的：

• 开发者提交代码到版本控制仓库
• CI服务器自动拉取代码
• 自动执行构建、编译
• 自动运行单元测试、集成测试
• 生成构建报告和测试报告

什么是持续交付？

持续交付是持续集成的「升级版」。它保证你的代码不仅能够集成，还能随时部署到生产环境。

我记得有一次，产品经理突然说：「这个功能明天就要上线，客户等着用。」

如果是传统模式，我得先合并代码、跑测试、打包、配置环境、手动部署……一套流程下来，至少半天。

但有了持续交付，我只需要点一个按钮，或者执行一条命令，代码就能自动部署到生产环境。因为所有的测试、构建、配置都已经在流水线里自动化了。

持续交付的关键在于：

• 代码始终处于可部署状态
• 部署过程完全自动化
• 人工只需要做「是否部署」的决策

什么是持续部署？

持续部署比持续交付更进一步。它连「点按钮」这一步都省了。

代码通过所有测试后，自动部署到生产环境。整个过程不需要人工干预。

你想想看，这听起来是不是有点吓人？代码改完就直接上线了？

是的，很多公司不敢这么做。但像Netflix、Amazon这样的公司，每天部署几百次，靠的就是持续部署。

当然，持续部署对测试覆盖率、监控告警、回滚机制的要求非常高。我曾经在一个金融项目里尝试过持续部署，结果因为测试用例覆盖不全，线上出了个bug。嗯，从那以后，我建议团队先做好持续交付，再考虑持续部署。

为什么需要CI/CD？

这个问题，我可以用一个真实的案例来回答。

之前我带过一个团队，项目周期三个月。前两个月大家各自开发，第三个月开始集成。结果呢？集成花了整整三周，测试又花了两周。最后上线的时候，离deadline只剩两天。

为什么会这样？因为集成太晚了。问题发现得越晚，修复成本越高。

CI/CD解决的就是这个问题。它让你：

• 尽早发现集成问题
• 尽早发现代码缺陷
• 尽早获得反馈
• 尽早交付价值

说白了，CI/CD就是把「最后才做」的事情，变成「每天都做」。

CI/CD的核心价值与收益

我总结了一下，CI/CD带来的收益主要有这么几点：

价值维度	具体收益	我的亲身经历
降低风险	问题早发现、早修复	有一次CI跑出测试失败，发现是数据库连接池配置错了，只影响测试环境，没上生产
提高效率	自动化代替手动操作	以前发版要2小时，现在10分钟搞定
增强信心	每次提交都经过验证	团队敢频繁提交代码，不再害怕「搞崩主干」
快速反馈	几分钟内知道代码质量	开发者提交后去喝杯咖啡，回来就看到结果
减少重复劳动	构建、测试、部署全自动化	运维同学终于不用半夜爬起来手动部署了

CI/CD的核心逻辑

下面这张图，是我自己画的CI/CD核心流程。你看一眼就能明白整个体系是怎么运转的。

你看，从代码提交到持续集成，再到持续交付和持续部署，每一步都是环环相扣的。反馈循环保证了问题能快速被发现和修复。

最后说两句

CI/CD不是一蹴而就的。我见过很多团队，一开始雄心勃勃要搞CI/CD，结果搞了两周发现太麻烦，又回到手动模式。

我的建议是：从小处着手。先搞定持续集成，让每次提交都能自动构建和跑单元测试。等团队习惯了，再逐步加入自动化部署、集成测试、性能测试。

记住，CI/CD的核心不是工具，是文化。是那种「频繁提交、快速反馈、持续改进」的开发文化。