CI/CD 概述：持续集成与持续交付

我记得刚入行那会儿，团队还过着「代码写完就往服务器上一扔」的日子。后来项目越来越大，每次合并都能炸出一堆冲突，部署更是心惊胆战。直到我真正上手搭了一套 CI/CD 流水线，才明白什么叫「真香」。这一章，咱们就把 CI/CD 的概念、价值和与传统方式的区别，掰开了讲清楚。

持续集成（CI）到底是个啥？

持续集成，说白了就是：开发人员频繁地把代码合并到主干，每次合并都会触发自动构建和自动测试。你想想看，如果一个团队 10 个人各写各的，等到周五才统一合，那冲突得有多酸爽？

我做过一个微服务项目，服务拆了 20 多个，每个服务的开发者都在自己的分支上开发。一开始大家约定每周五下午合并，结果每次合完都要花一整天修冲突和修复回归的 bug。后来我们换成了 CI：每个人每天至少合并一次，合并前自动跑单元测试、lint 检查、集成测试。不到两周，团队的发布节奏就从每周一次变成了每天两三次。嗯，这就是 CI 的价值。

持续交付（CD）又是什么？

持续交付是在 CI 的基础上，让代码随时都处于可以部署到生产环境的状态。它不是自动部署到生产，而是让部署这件事变成一个「一键操作」——只要通过了所有自动化验证，点一下按钮就能上线。

我个人习惯把 CD 分成两层：

• 持续交付：代码通过所有自动化测试后，自动部署到类生产环境（staging），人工确认后一键上线。
• 持续部署：所有自动化验证通过后，自动发到生产环境，连确认按钮都不需要。

我在电商平台做过一个活动页面的持续部署流水线。每次修改文案或图片，从提交代码到上线，全程自动化，平均耗时 4 分钟。你想想看，如果没有 CD，每次改个 banner 都要走审批、手动打包、手动上传、手动重启服务器……那效率得多低？

CI/CD 到底能带来什么价值？

我总结了四个核心价值，用一张表说清楚：

价值维度	传统流程	CI/CD 流程
反馈速度	几天甚至几周才能发现代码问题	提交后几分钟内自动反馈
发布频率	月或季度发布一次	每周甚至每天发布多次
缺陷率	大量集成问题堆积到发布前	小步快跑，问题早发现早修复
团队协作	各自为战，冲突频繁	频繁同步，冲突及早解决

我参与过一家创业公司的项目，他们上线之前要手动跑 3 小时的回归测试，而且经常漏测。后来我们把测试全部自动化，嵌到 CI 流水线里，每次提交自动跑。结果呢？线上 bug 减少了 60% 以上。其实道理很简单——机器比人靠谱，重复的事情让它自动做，人才能去解决更复杂的问题。

跟传统开发流程对比，差距在哪？

传统开发流程，最常见的就是「瀑布模型」或者「大版本交付」。我早年做银行项目的时候就是这种模式：需求评审 → 设计 → 编码 → 测试 → 上线，每个阶段都要走完才能到下一个。代码写完可能要等一个月才开始集成测试，然后发现一堆接口对不上的问题，改完再等一个月。

这种模式有几个明显痛点：

• 集成地狱：所有代码在最后一刻才合并，冲突成堆，修复代价极高
• 反馈滞后：写了一个 bug，可能两周后才被发现，上下文全忘了
• 部署繁琐：依赖人工操作，容易出错
• 信心不足：每次上线都像在赌博，出了事故要通宵回滚

反观 CI/CD 流水线，它是一种「持续验证」的思维。你每次提交代码，流水线都会自动执行：

1. 拉取代码
2. 编译构建
3. 运行单元测试
4. 运行集成测试
5. 代码质量检查
6. 打包制品
7. 部署到测试环境

我曾经遇到过一个经典坑：某个同事提交了一个改动了全局静态变量的代码，在本地测试通过了，但 CI 跑集成测试时直接全体失败。如果按传统方式，这个 bug 可能要到测试阶段才能被发现，那时已经过了好几天。但在 CI 流水线里，5 分钟就暴露了，同事当场就回滚了提交。所以这个机制特别适合快速迭代的场景。

CI/CD 与 DevOps 的关系

很多人容易把 CI/CD 和 DevOps 混为一谈。我说一个简单理解：DevOps 是文化、理念和流程的集合，而 CI/CD 是落地 DevOps 最关键的技术实践。没有 CI/CD，DevOps 就像空中楼阁。

我画了一张图，把 CI/CD 的典型流程和核心节点串起来，让你一眼看明白：

几种常见的 CI/CD 工具

工具不重要，但知道几个主流的能帮我们快速上手。我做个小列表：

工具	特点	我个人习惯用在哪
Jenkins	老牌、插件生态丰富、可自托管	企业内部需要高度定制的流水线
GitLab CI	与 GitLab 深度集成、配置简洁	团队已经在用 GitLab 时首选
GitHub Actions	生态活跃、市场丰富、云原生	开源项目或小团队快速搭建
CircleCI	速度快、缓存机制好	对构建速度要求高的场景

其实工具选哪个都行，关键是把「频繁提交、自动验证、快速反馈」这个闭环跑起来。我以前带过一个团队，他们用 Jenkins 但配置得特别重，每次改流水线都要运维来改，反而拖慢了效率。嗯，这里要注意：工具应该是为流程服务的，别让工具反过来绑架你。

一些避坑指南

我踩过的坑不少，分享几个印象深的：

• 测试写得太少或太慢：CI 流水线里如果测试跑两个小时，开发者就会想跳过它。我曾经负责过一个项目，单元测试覆盖率不到 20%，集成测试还经常超时。后来我强制要求每次提交必须跑通过所有测试，并且把测试用例优化到 10 分钟内完成。效果立竿见影。
• 忽略环境一致性：开发环境和 CI 环境不一样，经常出现「在我机器上能跑」的尴尬。我的做法是从一开始就用 Docker 容器化构建环境，保证完全一致。
• 流水线太复杂：有些人喜欢在一条流水线里塞进代码扫描、安全审计、性能测试、甚至人工审批……我建议先做最简单的：构建 + 单元测试 + 打包。跑通了再逐步加别的。