2、核心概念扫盲：什么是持续集成(CI)？什么是持续交付(CD)？自动化测试在其中的角色。

很多刚接触 DevOps 的同学，会把 CI/CD 当成一个词来记。其实它俩分工完全不同。我见过不少团队，CI 跑得挺欢，一到 CD 就卡壳——说白了，就是没搞清楚「集成」和「交付」到底差在哪。

这一章，咱们把这两个概念拆开揉碎。顺便聊聊自动化测试在这条链路上到底扮演什么角色。嗯，这块要是理解偏了，后面整个 pipeline 都可能白搭。

2.1 持续集成（CI）——让代码永远处于可集成状态

持续集成，英文叫 Continuous Integration。核心就一句话：频繁地把开发者的代码变更合并到主干，并且每次合并都自动验证。

我早年在一个传统项目里，团队两周才合并一次代码。结果呢？合并那天全组人坐在一起，手动解决冲突，一搞就是大半天。更惨的是，合并完发现编译都过不了——因为有人改了接口签名没通知大家。那次之后，我坚决推了 CI。

你想想看，如果每次提交代码后，系统都能在几分钟内告诉你「这次没问题」或者「这里炸了」，你的开发节奏会顺畅多少？这就是 CI 的价值——尽早发现问题，降低集成风险。

2.2 持续交付（CD）——让每次提交都能随时发布

持续交付（Continuous Delivery）是 CI 的下一站。它保证：每次通过 CI 验证的代码，都处于可部署到生产环境的状态。

注意我的用词——「可部署」不等于「立即部署」。持续交付强调的是「发布决策由人来做，但发布能力由自动化来保障」。

维度	持续集成（CI）	持续交付（CD）
关注点	代码能否合并成功	代码能否发布到生产
产出物	构建产物 + 测试报告	可部署的制品 + 环境验证
触发方式	代码提交	CI 通过后自动触发
人工介入	通常不需要	发布前需要审批
失败影响	阻塞后续提交	阻塞发布流水线

我曾经帮一个金融客户搭 CD 流水线。他们之前每次发版都要手动打包、手动上传、手动改配置——一套流程走下来至少半天。后来我们把整个流程自动化了，从代码提交到生成可部署的 Docker 镜像，全程不到 10 分钟。发布经理只需要点一下「确认」按钮。

2.3 持续部署——比持续交付更进一步

还有个概念叫持续部署（Continuous Deployment）。它和持续交付的区别就一句话：持续部署把「人工确认」这一步也自动化了。

也就是说，每次代码通过所有测试，系统自动把它部署到生产环境。听起来很爽对吧？但说实话，我在实际项目中很少见到完全自动化的持续部署。除非你的业务容错率极高，或者有完善的灰度发布和回滚机制。

2.4 自动化测试在 CI/CD 中的角色

好，现在咱们聊聊自动化测试。没有自动化测试的 CI/CD，就像没有刹车的跑车——跑得快，但停不下来。

自动化测试在 CI/CD 链路中扮演三个关键角色：

1. 质量守门员——每次代码提交，自动跑测试。不过关，不让合并。
2. 风险探测器——在集成阶段发现回归问题、接口变更、性能退化。
3. 发布决策依据——测试通过率、覆盖率、失败用例，直接决定能不能发版。

我习惯把测试按「反馈速度」分层放进 CI/CD 流水线：

• 提交阶段（< 5 分钟）：单元测试 + 代码规范检查。跑得最快，拦截最基础的问题。
• 集成阶段（< 30 分钟）：接口测试 + 组件测试。验证模块间协作是否正常。
• 预发布阶段（< 2 小时）：端到端测试 + 性能测试。模拟真实用户场景。

你想想看，如果每次提交都要跑一遍完整的端到端测试，开发者的耐心早就被磨没了。所以测试分层很重要——把跑得快的测试放在前面，把跑得慢的测试放在后面。这样既能快速反馈，又不放过深层次的问题。

2.5 一张图看懂 CI/CD 与自动化测试的关系

下面这张图，是我自己画的一个简化版 CI/CD 流水线。它展示了代码从提交到部署的完整路径，以及自动化测试在每个环节的介入点。

这张图里，自动化测试不是独立存在的环节——它嵌入在 CI 和 CD 的每一个阶段里。没有测试的 CI/CD，本质上只是「自动编译 + 自动部署」，质量风险一点没降。

2.6 小结

这一章咱们把三个核心概念理清了：

• 持续集成（CI）：频繁合并代码，自动构建和测试，尽早发现集成问题。
• 持续交付（CD）：保证每次通过 CI 的代码都处于可发布状态，但发布决策由人来做。
• 自动化测试：CI/CD 的质量基石。没有它，流水线跑得再快也是白跑。

我个人习惯把 CI/CD 比作「高速公路」，自动化测试就是路上的「收费站」。收费站越多，通行速度越慢，但事故率越低。怎么平衡速度和安全性？这就是咱们后面章节要聊的内容了。