CI/CD 概述：什么是持续集成、持续交付、持续部署

咱们开门见山。CI/CD 这三个字母，你在招聘 JD、技术博客里肯定见过无数遍。但说实话，很多团队其实没真正搞清楚它们各自管什么、边界在哪。我刚开始带 DevOps 团队那会儿，也犯过混淆的毛病。

那今天咱们就把这三兄弟掰开揉碎，讲明白。

持续集成（Continuous Integration，CI）

持续集成，说白了就是：开发人员频繁地把代码合并到主干，然后自动构建、自动测试。频率多高？我倾向于每天至少合并一次，甚至每个功能分支合并后都触发。

为什么要这么干？你想想看，如果大家各自在分支上闷头写两周，最后合并的时候发现冲突几百个、测试全红，那心情得多糟。我记得有一次，一个团队两周没合代码，最后合并花了三天，还引入了一个线上 bug，差点回滚。从那以后我定了规矩：分支存活时间不超过一天。

CI 带来的好处很直接：

• 快速发现集成错误
• 减少合并冲突
• 每次提交都有可验证的构建产物

持续交付（Continuous Delivery）

持续交付是在 CI 的基础上再往前走一步。它保证：每次通过 CI 的代码，都可以一键部署到类生产环境。注意这里的重点是“一键”，而且部署的目标是测试或预发布环境，不是直接上线。

我经常跟团队说：持续交付不是部署到生产，而是 随时准备好部署到生产。

怎么做到的？自动化部署流水线 + 环境一致性 + 配置管理。我个人习惯在流水线里加入自动化验收测试、性能测试、安全扫描。只要这些全绿，产物就进入“就绪”状态，业务方可以按需触发生产部署。

阶段	输入	输出
CI	代码提交	通过测试的构建产物
持续交付	构建产物	可部署到预生产环境的制品
持续部署	制品	直接部署到生产

这里有个常见误区：很多人把持续交付等同于自动部署到生产。其实不是的。持续交付的决策权还在人手里——业务方点一下按钮才上线。我在某金融客户那里见过，他们合规要求必须人工审核后才能上线，所以他们做到持续交付，但绝不搞自动部署。

持续部署（Continuous Deployment）

这才是真正的“全自动”。每次代码通过所有关卡，流水线自动把产物部署到生产环境。没有人手工干预。

我曾经帮一个互联网创业团队搞持续部署，他们测试覆盖率才 30%，我说不行，至少要 80% 才能跑。他们嫌慢，强行上线，结果连续三次把有 bug 的代码推到生产，用户体验直线下降。后来我们花了三个月补测试，才重新启动持续部署流水线。

所以我的建议是：持续部署不是银弹。它更适合那些测试完备、变更频率极高（一天数十次）的 SaaS 服务。你想想看，如果你的产品是银行核心系统，一年只发两三次版本，那持续部署反而增加风险。

三者的层次关系

用一个简单的递进关系来理解：

1. CI：保证代码质量，频繁合并，快速反馈。
2. 持续交付：保证代码随时可部署到预生产环境，但部署到生产由人决定。
3. 持续部署：保证代码通过测试后自动部署到生产，无需人工。

大多数团队从 CI 起步，逐步走向持续交付，只有少数团队能安全进入持续部署。我自己带过十几个项目，真正走到持续部署的也就两三个，而且都是做云端微服务的。

一张图看懂 CI/CD 流程

下面这张图把三个概念串在一起。你可以看到代码从提交到落地的完整路径，以及每个环节对应的能力。

落地关键点总结

光有概念没用，我列几条实战中必须注意的：

• 流水线要快：CI 阶段我要求 10 分钟内必须出结果，超过 30 分钟大家就不想合代码了。
• 测试覆盖率不是万能的，但没有覆盖率是万万不能的。我要求核心模块单元测试至少 80%，集成测试覆盖主要路径。
• 环境一致性：预生产环境和生产环境必须尽可能一致。我踩过最大的坑是预生产用 Docker，生产用物理机，结果网络配置不一样导致上线失败。
• 版本管理要规范：我习惯用 GitFlow 或 Trunk-Based Development，搭配语义化版本号，确保每个产物可追溯。