多年来，团队一直将持续集成（CI）和持续交付（CD）捆绑为一个概念：CI/CD。这种简写暗示着一个无缝的管道，但实际上，它造成了混淆，并隐藏了 CI 和 CD 解决非常不同问题的事实。

CI 就像工厂中的质量控制过程，在安装之前仔细检查和测试每个组件，以确保其安全并符合标准。另一方面，CD 是物流公司，使用深思熟虑的策略将成品交付给客户，监控其旅程，并在出现问题时有安全返回的计划。将它们视为一个通常会创建未优化的工作流程，模糊责任分离，并导致对需要什么的困惑。

为了进一步论证，以下是一些你应该将它们视为单独事物的具体原因：

不同目标

• 持续集成（CI）：质量和信心，核心问题是“我的更改是否足够安全可以合并？”，重点领域是在代码进入主分支之前验证其符合质量、安全和合规标准，实践包括自动化构建、单元和集成测试、静态分析、漏洞扫描、依赖项检查、工件签名和软件物料清单（SBOM）生成，结果是可信任的工件可以放心地向下游推进，例如开发者提交拉取请求时，CI 确保在几分钟内更改能够编译、通过测试、不破坏依赖项且安全可集成。
• 持续交付（CD）：安全和渐进式推出，核心问题是“我们能否可靠且安全地将此工件交付给其预期的消费者——无论是人、服务还是 API？”，重点领域是构建后的风险管理、治理和客户影响，实践包括环境升级（开发→暂存→生产）、金丝雀或蓝绿部署、功能标志管理、合规门、审计日志和回滚程序，结果是可靠且可观察的发布过程，以最小的中断交付更改，例如新功能逐步向 1%的用户推出，在确认稳定性后扩展到 100%。

不同时间线

• CI：快速、持续和高频，每次提交和拉取请求都会触发 CI，强调速度——反馈循环必须很短（几分钟，而不是几小时），以便开发者能够立即采取行动，失败应阻止合并，防止损坏的代码进入主线，类比像工厂对每个零件的检查，例如开发者一天推送 10 次提交，期望 CI 快速验证每一次。
• CD：深思熟虑、风险意识和分阶段，推出以较慢的节奏进行——每天、每周或按需，取决于风险容忍度，需要跨环境协调、批准，有时需要遵守法规合规，监控窗口可能在发布后数小时或数天延伸，类比像物流公司跨境运输货物——时间很重要，许可证很重要，必须有召回计划，例如金融服务公司可能在每次更改时运行 CI，但由于合规要求仅每周发布生产更新。

不同团队

• CI 所有权：开发者和平台团队，目标是让开发者快速移动而不破坏东西，责任包括维护构建系统、测试框架和集成信号，平台团队提供标准化的 CI 基础设施、缓存、远程执行和可重用的构建规则，以便每个团队不必重新发明轮子，例如平台工程团队运行 CI 集群，但开发者负责测试覆盖范围和修复损坏的构建。
• CD 所有权：发布工程、SRE、运营和产品，目标是在发布期间保护客户和业务成果，责任包括定义推出策略、监控生产、执行治理和在需要时触发回滚，产品所有者可能设置发布节奏；运营团队确保合规性和可靠性，例如 SRE 拥有监控仪表板和回滚自动化，而发布经理协调跨地区的分阶段推出。

不同抽象

• CI 抽象：构建、测试和验证，包括构建管道——自动工作流，用于编译和测试代码，确保每次提交都产生一致的结果；依赖项管理——标准化处理库和包，以避免版本漂移和漏洞；远程执行和缓存——通过分发工作和重用输出来加快构建/测试；工件签名和存储——确保工件是防篡改、可追溯的，并可用于下游交付；SBOM 和合规检查——在周期早期生成软件物料清单并验证合规性。
• CD 抽象：发布、风险和控制，包括环境升级——将工件通过开发、暂存和生产环境移动，并带有明确的验证门；推出策略——蓝绿、金丝雀或渐进式策略，以减少爆炸半径和管理风险；功能标志——解耦部署和发布，实现安全切换、实验和即时回滚；可观察性和监控——内置健康检查和警报，在推出期间验证成功；回滚和治理——在失败时自动回滚，并具有合规性和审计控制以确保问责制。

一个“管道”的危险

将 CI 和 CD 强制纳入一个 YAML 或工作流中，会以使系统僵化和脆弱的方式耦合这些抽象。构建失败不必要地阻止发布，推出策略与开发者测试纠缠在一起，所有权变得模糊。这降低了敏捷性并增加了运营风险。

结论

CI 确保每次更改都可以安全合并，CD 确保每次更改都可以安全发布。CI 和 CD 都很关键，但将它们视为一个会模糊它们的目的并降低它们的影响。为了构建安全、可扩展且真正有能力的开发者平台，我们必须停止隐藏在“CI/CD”的简写背后，而是将 CI 和 CD 作为不同的、可组合的学科进行投资。有了明确的分离，组织可以兼得两者之美：开发者自信地快速迭代，运营安全地交付并具有控制。将它们合并为一个概念可能听起来很方便，但实际上会造成混乱、减缓进度并使系统更加脆弱。