CI/CD 到底是什么：一条管道，七道工序，127 倍的交付差距
前言
" CI/CD 这三个字母被说烂了。招聘要求里人人都会写，但真问一句"持续交付和持续部署差在哪"，能答清的不多。
Fortinet 的网络安全术语库有一篇讲 CI/CD 的科普文，写得很系统——从概念、数据、实施步骤到安全防护都有。这篇把它拆开揉碎，配上几张图，一次讲明白。
一、CI 和 CD，其实是两件事
CI/CD 是一种软件开发方法论：把开发过程中集成、测试、部署三个阶段自动化，让频繁的代码变更能被可靠地测试、验证、上线。
拆开看：
持续集成（CI）——开发人员每天多次把代码提交到共享仓库，每次提交都触发自动化测试。目的只有一个：别让小错误滚成大问题。改动越早暴露，修复越便宜。
持续交付/部署（CD）——这里有个容易混的分叉：
- 持续交付：代码始终处于可部署状态，发版只需人工点一下头
- 持续部署：测试全过就直接上生产，无人值守
Netflix 用的是后者——每天部署代码数千次。
二、值得吗？看数据
2024 年 DORA 报告的数据：采用成熟 CI/CD 实践的高绩效团队，和低绩效团队比——
- 交付周期（从提交到生产）缩短 127 倍
- 部署频率提升 8 倍
- 故障率降低 182 倍
不只是快，还更稳。这是很多人对 CI/CD 的误解——以为提速必然牺牲质量，数据说的是反话：自动化测试频繁验证，故障反而少。
另外两个数：Feature flags（功能开关）用户部署频率提升 84%、可靠性提高 48%、故障恢复快 46%；近 70% 用功能开关的团队，发布只需 5 人以内。基础设施即代码（IaC）实践成熟的团队，安全态势更强的占 86%。
三、一条管道的七道工序
一次提交从进仓库到上线，标准管道走七步：
几个细节值得单独说：
分支要短命。高绩效团队的做法是分支存活不超过 24 小时、合并的分支不超过三个——主干开发模式。长期分支 + 延迟合并，是表现差组织的典型特征。
工件要进仓库。构建产物存进 Nexus 或 Artifactory 这类专用仓库，打版本标记。出问题时能快速回滚到任意版本，这不是可选项。
测试是分层的。单元测试管单组件，集成测试管组件交互，功能测试从用户视角看整体，再往上是性能测试和安全扫描。每层堵一类问题，缺一层就漏一类。
验收是最后一关。端到端模拟真实使用、负载测试压极限、业务方做 UAT。过了这关才算"具备部署准备状态"。
四、上线方式：四种部署策略
代码进了生产环境只是开始，怎么切流量决定了出事的爆炸半径：
选型逻辑很朴素：蓝绿买两倍资源买秒级回滚；金丝雀用最小用户代价试错；滚动是容器时代的默认解；全量重部署只留给不得不做的重大变更。
五、管道本身也是攻击面
这是 Fortinet 这篇文章最有价值的部分——大多数 CI/CD 科普不谈安全，但管道恰恰是新攻击面。
一条没设防的管道可能：泄露敏感数据、引入带漏洞的组件、被未授权访问。常见威胁四种：不安全的代码库、配置错误、有缺陷的第三方库、机密管理不当。
防护分六层：
| 防护层 | 管什么 |
|---|---|
| SCA 源成分分析 | 第三方依赖的已知漏洞，进生产前报警 |
| SAST 静态安全测试 | 自研代码的注入、溢出、输入校验缺陷 |
| 访问控制 | 每个管道工具都要有认证，最小权限原则 |
| 密钥管理 | 密码/API key/令牌严禁硬编码，专用方案存取 |
| 镜像仓库扫描 | 容器镜像入仓库时扫漏洞，兜住构建期遗漏 |
| 运行时监控 | 上线后的日志、网络指标、系统活动异常检测 |
其中密钥管理是最常翻车的：把 API key 硬编码在配置文件或 IaC 模板里，任何能读到文件的人都能看到凭证。专用密钥管理方案按需分发，是底线不是加分项。
六、工具怎么选
主流就五个，按场景挑：
- Jenkins：老牌开源，定制能力最强，Netflix、LinkedIn、NASA 在用。适合复杂需求，代价是维护成本
- GitHub Actions：2019 年推出，2024 年使用量同比涨 30%，达到 105.4 亿分钟。GitHub 生态内的团队几乎默认选它
- GitLab CI：代码管理、测试、部署一体。Forrester 2024 年报告说用集成式平台的团队功能交付量提升 50%，开发者每年省 300+ 小时
- CircleCI：云原生、上手快，适合不追求复杂功能的小团队
- TeamCity：JetBrains 出品，本地部署优化，适合有严格治理要求的大企业
未来方向按文章的说法：GitOps、平台工程集成、无服务器架构、低代码管道，以及 AI 预测管道故障、优化测试运行。
七、八个常见的坑
文章列的实施误区，每条都有真实项目摔过：
- 过度关注工具——工具该支持工作流，不是规定工作流。没有明确目标，再好的工具也是摆设
- 文化抵抗——团队抵制时技术方案必死，变革管理先做
- 环境不一致——开发环境好好的，一到生产就挂，时间全耗在排查环境差异上。容器 + IaC 是解
- 测试覆盖不足——为快牺牲测试严谨性，要么发缺陷要么退回手动测试，两头堵死
- 反馈周期太长——反馈要几小时而不是几分钟，提交频率自然掉下来
- 安全后置——开发完了才做安全验证，返工代价最高。安全要长在管道里
- 监控缺失——部署完没人盯，问题拖到用户投诉才发现
- 过度复杂——管道复杂到没人看得懂，故障排查能力直接归零。从核心功能起步，验证价值再加
第一条和最后一条最值得警惕：用 CI/CD 不是目的，工具越简单越可靠，这条经验在 AI 时代一样成立。
记住
CI/CD 的本质是把手动流程变成自动化管道：提交 → 构建 → 测试 → 验收 → 部署，每次提交都走一遍。
高绩效团队的交付周期是低绩效的 1/127，故障率是 1/182——快和稳不冲突，自动化测试频繁验证才是两者兼得的前提。
别忘了管道自己也是攻击面：依赖扫描、密钥管理、最小权限，一样都不能少。
参考资源
- 原文：Fortinet 网络安全术语库《持续集成/持续交付（CI/CD）》
- 数据来源：DORA 2024 年报告、Forrester 2024 年 10 月报告、GitHub Octoverse、HashiCorp 2024 云成熟度报告