三个概念怎么区分
CI（持续集成）指开发者频繁把代码合入主干，每次合入自动触发构建与测试，尽早暴露集成错误；它聚焦合入前验证，不涉及把版本发布给用户。CD 有两种常见含义：持续交付（Continuous Delivery）要求流水线把验证过的制品一直准备到随时可发布，上生产的时机由业务方人工决定；持续部署（Continuous Deployment）把上生产也自动化，验证通过即发布，不再有人按按钮的环节。区分三者的关键口径：产物能否随时发布、发布是否还需要人决策。三者是能力阶梯，不是互相替代的口号：先做到主干常绿（CI），再让产物随时可发（交付），最后才谈自动上线（部署）。落地顺序建议从 CI 开始：没有稳定的自动验证，后面两级只是把不可靠的流程搬得更快。
基本信息
| 适用平台 | 任何使用版本控制与流水线的团队 |
|---|---|
| 判断问题一 | 验证失败的版本，产物还能随时发布吗 |
| 判断问题二 | 上生产是否需要人工决定时机 |
| 落地顺序 | 先绿主干，再随时可发，最后自动上线 |
| 阅读对象 | 研发、测试、发布经理、运维 |
三者对比
| 概念 | 自动化边界 | 发布决策 |
|---|---|---|
| 持续集成 CI | 合入前后自动构建与测试 | 不涉及发布 |
| 持续交付 CD（Delivery） | 流水线推进到预发，产物可随时发布 | 人工决定何时上生产 |
| 持续部署 CD（Deployment） | 验证通过后自动发布到生产 | 由流水线与门禁决定 |
典型使用场景
- 多人协作的主干分支：每日多次合入，用 CI 保证每次合入后主干可构建、测试可过。
- 发布节奏由业务决定的团队：用持续交付把制品准备到预发，市场活动与合规窗口由人选择。
- 低风险高频发布的内部服务：持续部署让修复与功能随提交自动上线，批次更小、出问题更好回退。
- 强监管环境：在链条中保留人工审批与审计记录，而不是追求全自动上生产。
- 配置与基础设施仓库：同一套三层划分同样适用，配置变更走同等验证与晋级流程。
- 评估团队成熟度：先绿主干再谈可发布，跳级常导致流水线建了但没人敢发。
- 对外承诺发布窗口：先用交付链条保证预发验证完备，再由业务决定上线时间，避免脚本赶工上线。
判断口径
判断口径
同一提交流水线通过后：
- 只做到可随时发布 = 持续交付
- 自动上线且客户可见 = 持续部署
# 自查问题
- 回归失败时产物还能发吗？不能 -> 未达持续交付
- 上生产需要人点按钮吗？需要 -> 不是持续部署DORA《Accelerate》研究显示：版本控制、测试自动化、部署自动化等能力与交付绩效正相关，持续交付是其中一组关键工程能力。
人工门不等于低效：持续交付中的审批通常只针对上生产一步，构建、测试与预发部署全自动，审批与自动化并不冲突。
把有流水线等同于持续交付是常见误判：若回归未过产物就发不出去，或回滚通道从未演练，实际仍停留在自动化构建阶段。