📚 课程目录第1章 CI/CD概念入门

1、CI/CD概念入门：持续集成、持续交付、持续部署

咱们先聊聊最基础的东西——CI/CD到底是什么。很多新手刚接触DevOps的时候，总被这几个词绕晕。坦白讲，我当年刚入行那会儿也犯过糊涂：持续集成、持续交付、持续部署，名字长得像三胞胎，实际干的事儿差异挺大。

持续集成，说白了就是让开发团队频繁地把代码合并到主干。你想想看，传统的方式是大家各写各的，等到上线前一两天才开始合并。结果呢？冲突堆成山，一测全是bug，然后手忙脚乱熬通宵。我在项目中遇到过好几次这种“合并地狱”，真的很痛苦。

  核心要点：每次代码提交都自动触发构建和单元测试，让问题在几分钟内暴露，而不是拖到上线前。

我自己习惯的做法是：每个开发分支至少每天合并一次，配合GitHub/GitLab的Webhook，只要push就会跑一套流水线。比如下面的伪流程：

代码提交 → 触发Webhook → 拉取代码 → 编译构建 → 运行单元测试 → 生成测试报告 → 通知结果

CI的成败关键在于：构建脚本要快（最好5分钟以内），测试要可靠（不要有flaky test）。我曾经因为一个测试用例偶尔超时而浪费整个团队半天时间排查……从那以后，我对测试稳定性特别敏感。

持续交付是CI的下一站。代码通过CI验证后，自动部署到类生产环境（比如staging），再进行一轮更全面的测试——集成测试、验收测试、性能测试。通过后，这个版本就“可供发布了”。

注意，持续交付不会自动推送到生产，它只是让你拥有一个随时可以手动部署的制品。你想想看，老板说“今晚发版”，你点一下按钮就好，而不是再从分支重新构建一遍。我记得有一次紧急修复线上bug，持续交付管道里恰好有一个已经验证过的版本，直接点发布就解决了，省了至少2小时。

个人经验：持续交付的关键是“一键部署” + “环境一致性”。我最开始踩过一个坑——开发环境和staging环境的配置文件不一样，结果测试通过了，上线就挂。所以现在我的管道里一定会包含环境校验步骤。

持续部署是持续交付的完全自动化版本。所有通过测试的版本，自动推送到生产环境。没有任何人工审批环节。说白了，只要你的CI/CD管道判定没问题，代码就直接上线了。

这种做法风险很大，所以一般用于对快速迭代要求极高、且有完善灰度能力和监控回滚的团队。比如一些互联网公司的SaaS服务、移动端后端。但在金融、医疗等行业，合规要求不允许直接全自动部署，一般会在持续交付阶段加一个人工审批。

特别注意：持续部署不是适合所有场景的银弹。我曾经给一个客户搭建管道，他们要求全自动上线，结果有一次因为数据库迁移脚本顺序错了，导致线上数据丢失了半小时。从那以后，我建议所有含有数据库变更的场景至少保留一个“手动审批”环节。

为了更直观地看清差异，我整理了一个对比表格：

维度	持续集成（CI）	持续交付（CD）	持续部署（CD）
基本动作	合并代码 + 构建测试	CI + 部署到类生产 + 验收测试	持续交付 + 自动上线生产
最终产出	可运行的构建制品	可发布的生产候选版本	直接上线的生产版本
是否自动上线	否	否（需手动批准）	是
风险等级	低（仅影响开发环境）	中（影响staging等）	高（直接影响用户）
常用度	几乎必用	大多数团队使用	较少团队使用

它们的联系其实很清晰：CI是基础，持续交付是CI的扩展，持续部署是持续交付的自动化升级。很多公司的管道实际上是这样一条链：

代码提交 → CI阶段（编译+单元测试） → 持续交付阶段（部署Staging+集成测试+性能测试） → 持续部署阶段（自动推生产）

当然，大多数公司会在持续交付和持续部署之间加一个“人工审批”的闸门。我自己的经验是：先跑通CI，再慢慢拓展到持续交付，持续部署永远放在最后一步，等团队对管道足够有信心了再去尝试。

嗯，这个关系其实很像一个漏斗：越往后推，自动化程度越高，风险也越大。我自己搭建管道时，会先把CI做到极致——哪怕团队只有两个人，我也会搭一套基本的CI。持续交付看团队成熟度，持续部署则一定等有了灰度发布和回滚能力才开搞。记住这个顺序，你的CI/CD之路会走得更稳。