CI/CD基础：持续集成与持续交付的概念、传统交付模式的痛点、CI/CD的核心收益
聊到云原生，绕不开的就是CI/CD。
说实话，我见过太多团队，工具链搭得花里胡哨，但连CI/CD的基本概念都没搞清楚。结果呢？流水线跑得挺欢，该出的问题一个没少。今天咱们就把这块地基夯实了。
一、什么是持续集成？
持续集成，英文叫Continuous Integration，简称CI。
说白了就是：开发人员频繁地将代码合并到主干分支，每次合并都自动触发构建和测试。
我习惯把它理解成「代码的体检中心」。你每次提交代码，系统就自动帮你做一次全面检查——编译能不能过？单元测试跑不跑得通？代码风格有没有问题？
核心要点：
- 频率要高：每天至少合并一次，甚至多次
- 自动化：构建、测试、静态分析全自动
- 反馈要快：几分钟内出结果，别让开发者等半天
我在项目中遇到过这样的团队：大家各写各的，两周才合并一次代码。结果合并那天，光解决冲突就花了一天，还引入了一堆bug。嗯，这就是典型的「集成地狱」。
二、什么是持续交付？
持续交付（Continuous Delivery，CD）是在CI的基础上，再加一步：确保代码随时可以部署到生产环境。
注意我的用词——「可以部署」，不是「自动部署」。这两者有本质区别。
持续交付强调的是：你的软件始终处于可发布状态。要不要点那个「发布」按钮，由业务方决定。
我的经验：
我曾经带过一个项目，上线前需要手动跑20多个测试用例，还要人工检查配置项。每次发布都像在拆弹。后来我们上了持续交付流水线，把验证过程全部自动化。发布从「心惊胆战」变成了「喝杯咖啡的功夫」。
三、持续部署 vs 持续交付
很多人把这两个概念搞混。我简单区分一下：
| 维度 | 持续交付 | 持续部署 |
|---|---|---|
| 部署方式 | 手动触发 | 自动触发 |
| 风险控制 | 有人为审批环节 | 完全依赖自动化检测 |
| 适用场景 | 大多数企业级应用 | 测试环境、SaaS产品 |
| 对测试要求 | 较高 | 极高 |
你想想看，如果你的业务是金融交易系统，你敢让代码自动部署到生产环境吗？反正我不敢。但如果是内部测试环境，自动部署完全没问题。
四、传统交付模式的痛点
聊完了概念，咱们看看传统模式到底哪里疼。
痛点一：集成周期长，冲突成常态
我记得刚入行那会儿，项目组规定每两周合并一次代码。每次合并前，大家先拉个会，分配好谁先谁后。然后就是漫长的冲突解决——你改了我没改的，我删了你刚加的。那场面，跟打仗似的。
痛点二：手动测试，效率低下
传统模式下，测试靠人工。开发写完代码，扔给测试同学。测试同学手动部署、手动执行用例、手动记录结果。一个版本测下来，少则两三天，多则一周。
更可怕的是，回归测试基本靠「感觉」。改了一个模块，其他模块有没有受影响？没人知道。
痛点三：发布窗口期，压力山大
传统项目通常有固定的发布窗口——比如每周五晚上。所有改动必须在窗口期内完成。一旦错过，就得等下一周。
我曾经经历过一次：周五下午发现一个bug，修复后已经过了窗口期。结果那个bug在生产环境躺了一周，用户投诉电话被打爆。嗯，那滋味不好受。
痛点四：环境不一致，线上翻车
「在我机器上明明是好的啊！」——这句话是不是很耳熟？
传统模式下，开发环境、测试环境、生产环境配置各不相同。依赖版本、操作系统、网络设置，任何一个差异都可能导致线上故障。
避坑指南：
我曾经接手过一个项目，开发用Windows，测试用CentOS 6，生产用CentOS 7。结果一个路径分隔符的差异，导致线上服务启动失败。从那以后，我坚持所有环境必须容器化，镜像一致，配置分离。
五、CI/CD的核心收益
说了这么多痛点，那CI/CD到底能带来什么好处？
收益一：快速反馈，早发现问题
CI/CD最直接的好处就是——问题发现得早。
你提交代码后，几分钟内就能知道编译是否通过、测试是否失败。如果出了问题，修复成本极低。想想看，一个bug在开发阶段发现，可能几分钟就修好了。要是到了生产环境才发现，那可能就是几小时甚至几天的排查和回滚。
收益二：减少重复劳动，提升效率
构建、测试、部署、通知——这些重复性工作全部交给自动化流水线。开发者只需要关注写代码本身。
我算过一笔账：一个10人团队，每天每人手动部署一次测试环境，平均耗时15分钟。一年下来就是900多个小时。上了CI/CD之后，这部分时间几乎归零。
收益三：降低发布风险
持续交付的核心思想是「小步快跑」。每次改动都很小，影响范围可控。即使出了问题，回滚也快。
你想想看，一次发布100个变更和一次发布1个变更，哪个风险更大？答案不言而喻。
收益四：提升团队信心
这个收益可能比较软性，但我认为它很重要。
当你的流水线每次都能稳定通过，当你的自动化测试覆盖率达到90%以上，团队对代码质量的信心会大大增强。发布不再是一件让人焦虑的事情，而是一个常规操作。
一句话总结：
CI/CD不是银弹，但它能帮你把「发布」这件事从「艺术」变成「工程」。
六、一个简单的CI/CD流水线示例
光说不练假把式。我给大家看一个最基础的流水线配置，用GitHub Actions实现：
name: CI/CD Pipeline
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: 安装依赖
run: npm ci
- name: 运行单元测试
run: npm test
- name: 构建镜像
run: docker build -t myapp:${{ github.sha }} .
- name: 部署到测试环境
run: |
kubectl set image deployment/myapp \
myapp=myapp:${{ github.sha }} \
--namespace=staging
这个配置做了几件事：
- 代码推送到main分支时触发
- 安装依赖并运行测试
- 构建Docker镜像
- 自动部署到staging环境
当然，这只是最基础的版本。实际项目中，你还需要加入代码扫描、安全检测、性能测试等环节。这些内容咱们后面的章节会详细展开。
一个小建议：
刚开始搭建CI/CD流水线时，别追求大而全。先跑通最核心的「构建-测试-部署」链路，再逐步添加其他环节。一口吃不成胖子，流水线也是。
好了，这一章的内容就到这里。下一章咱们聊聊「版本控制与分支策略」，这可是CI/CD的基石。选错了分支策略，后面怎么折腾都别扭。