CI/CD是什么？持续集成持续交付入门

多人并行开发时，代码冲突频繁，合并分支要来回沟通；发版前，手动构建、测试、部署一套流程下来，常要花掉大半天时间；上线依赖熟悉流程的同事......

类似的场景在研发团队很常见，也是 CI/CD 要解决的核心问题。

本文先详细介绍CI/CD概念，再厘清概念边界，讲清流水线运转的逻辑，之后给出一条从零开始的入门路径。

一、什么是 CI/CD

CI/CD 的英文全称是 Continuous Integration 与 Continuous Delivery 或 Continuous Deployment，中文译作持续集成与持续交付或持续部署。两部分合在一起，描述的是研发阶段从代码提交到发布上线的自动化链路。

它解决三类问题：

第一，多人并行开发时，代码频繁合并会互相影响，集成越晚，冲突越难处理。CI/CD 把集成动作提前并自动化。

第二，手动构建、测试、部署耗时长，占用人手。CI/CD 用流水线替代重复的人工操作。

第三，上线依赖个人经验，关键环节缺少验证。CI/CD 把构建、测试、部署的每一步都固化成可重复的执行步骤。

拆开看，C 指 Continuous，即持续，强调高频与自动触发。I 指 Integration，集成，对应代码合并与验证。D 指 Delivery 或 Deployment，交付或部署，代表发布前的一系列自动化准备。三者组合起来，体现的是频繁提交、自动验证、按需发布的工作方式。

二、持续集成交付和部署有区别

很多初学者把 CI/CD 当成一个整体，实际上里面三个概念的边界并不相同。持续集成解决代码合进来是否安全，持续交付和持续部署解决代码如何到达生产环境。

1. 持续集成是什么

持续集成是 CI/CD 的起点。它要求开发者频繁将代码合并到主干分支，每次合并都触发自动构建和自动测试。集成频率越高，问题暴露越早，修复成本越低。

现实中不少团队把集成集中在版本发布前，冲突集中爆发。正确做法是每人每天至少集成一次。持续集成的价值，正是把这种低频、高风险的操作变成高频、自动验证的过程。

2. 持续交付是什么

持续交付在持续集成之上增加部署准备环节。代码通过测试后，构建产物会被部署到与生产环境接近的准生产环境，确保任何时刻都具备一键发布到生产的能力。

与持续部署不同，持续交付保留人工确认步骤。点发布按钮仍由人完成。这种方式适合发布窗口受限、需要审批的团队，既享受自动化带来的效率，又保留对生产变更的控制。

3. 持续部署是什么意思

持续部署更进一步。代码通过全部测试后，系统自动将其部署到生产环境，全程无需人工点击发布。反馈链路最短，新功能上线速度最快。

代价是对自动化测试质量要求很高。测试覆盖不足时，自动部署会把未验证的改动直接暴露给用户。所以持续部署更适合测试体系成熟、回滚机制完善的团队。

4. 用一条对比表区分

三个概念的差异，可以用一张表直观对照。下表列出核心目标、触发动作和自动化程度。

容易混淆的是交付与部署：交付强调随时可发布，部署强调自动发布。两者只差一个动作，但这个动作决定了生产变更由人还是由系统触发。三者共同的前提都是自动化测试足够可靠，否则自动化程度越高，风险也越高。

三、CI/CD 流水线怎么运转

CI/CD 流水线（Pipeline）是从代码提交到部署上线的自动化流程链条。理解流水线，就理解了 CI/CD 的落地形态。一条流水线通常包含提交、构建、测试、部署、监控几个环节。

1. 提交代码自动触发

流水线的起点是代码提交。开发者将代码推送到共享仓库，合并请求创建、标签发布等事件都可能触发流水线。没有流水线时，集成靠人拉代码手动合并，冲突全靠自己解；有流水线后，事件一发生，后续步骤自动开启。

2. CI 自动构建和测试

触发后进入构建环节，系统拉取代码、安装依赖、编译打包，产物留存供后续使用。构建完成后自动运行测试，包括单元测试、接口测试等。测试脚本按预设顺序执行，任一步失败都会中断流水线，并把结果反馈给提交人。研发管理平台可以和 Jenkins 一类工具配合，把测试执行结果回传，失败的用例自动创建 Bug，避免在多个系统间来回切换。