持续交付与持续部署的分界落在“可发布”和“已上线”之间：前者把每次变更做成随时可发布的状态，上线与否由人决定；后者把上线动作也交给流水线，校验通过即进入生产。团队规划发布自动化程度时，真正要判断的是发布控制权放在哪里、风险由哪套机制承担、当前条件适合停在哪一档。本文按发布控制、风险承担、适用场景三个维度展开对照。
要点总览（TL;DR）
- 持续交付与持续部署的分界在“可发布”与“已上线”之间：前者由发布负责人决定何时上线，后者由流水线校验通过后直接进入生产。
- 持续交付把风险留在发布评审与发布窗口，由发布负责人承担；持续部署把风险前移到自动化测试、灰度、监控与回滚能力上，由工程体系承担。
- 发布频率低、合规评审重、变更影响面大的团队适合以持续交付为主；测试覆盖充分、灰度与回滚经过验证、变更粒度小的团队才适合推进持续部署。
- 多数团队适合渐进推进：先让所有通过校验的变更处于可发布状态，再选低风险服务试点自动上线，用发布记录、回滚耗时、变更失败率验证后再扩大范围。
同一口径下，两者的发布控制差在哪一步
把两种模式放到同一条流水线上看，构建、测试、制品产出这几个阶段的做法基本一致，差异集中出现在制品就绪之后：持续交付在这里设置一个人工决策点，持续部署则让流水线继续执行上线动作。用阶段对齐的方式比较，可以避免把“自动化程度高”笼统地等同于“不需要人”。
| 流水线阶段 | 持续交付 | 持续部署 |
|---|---|---|
| 构建 | 自动触发，产出可追溯的构建结果 | 自动触发，产出可追溯的构建结果 |
| 测试 | 自动化测试作为进入制品库的门槛 | 自动化测试作为进入生产的前置校验，覆盖要求更高 |
| 制品 | 生成带版本标识、可随时部署的制品 | 生成同一类制品，并直接进入发布流程 |
| 部署 | 可自动部署到预发或类生产环境 | 自动部署到生产环境 |
| 上线 | 由发布负责人决定何时、发布哪个版本 | 校验通过即上线，无人工放行环节 |
发布控制权的差别由此清晰：持续交付的控制点在“制品就绪之后、上线之前”，审批位置靠近发布动作，回滚通常由发布负责人根据上线后的观察决定是否触发；持续部署的控制点前移到流水线校验环节，审批以质量门禁的形式固化在流水线里，回滚更多依赖监控告警自动或半自动触发。两种模式都保留回滚能力，区别在于由谁在什么信号下启动。
需要说明的是，持续交付并不等于手动部署。部署到预发环境、执行数据库变更脚本等动作同样可以自动化，人工保留的是“是否对真实用户开放”这一判断。把这一点分清，团队在规划时就不会把持续交付误解为自动化程度不足的过渡状态。
风险承担：风险留在发布评审还是前移到流水线
两种模式都不消除发布风险，区别在于风险在哪个环节暴露、由谁承担。持续交付把风险集中在发布决策与发布窗口，由发布负责人承担：他需要判断当前版本是否值得在这个时间点上线，出问题时也由他决定回滚还是继续观察。持续部署把风险前移到自动化校验、监控与回滚能力上，由工程能力承担：流水线放行的每一个变更都直接面对用户，团队依靠测试覆盖、灰度策略和可观测性来兜底。
| 对比项 | 持续交付 | 持续部署 |
|---|---|---|
| 风险暴露位置 | 发布评审与发布窗口 | 流水线校验与生产监控 |
| 承担主体 | 发布负责人及其评审机制 | 工程团队与自动化设施 |
| 测试覆盖要求 | 关键路径覆盖，允许人工补充验证 | 核心链路自动化覆盖充分，回归可信 |
| 灰度能力 | 可选，按发布批次控制 | 必需，按流量或用户群逐步放量 |
| 可观测性 | 支持上线后观察与人工判断 | 指标、日志、告警需能支撑快速定位与自动回滚 |
这张表说明一个常被忽略的事实：推进持续部署并不会让风险变小，它把原本由人承担的判断责任转移给了系统。如果测试覆盖不足、监控指标缺失、回滚脚本长期未验证，那么前移的风险会以更快的速度、更大的影响面暴露出来。反过来，如果团队已经具备这些能力，持续交付阶段保留的人工评审就可能变成流程惯性，而非真实的风险控制。
因此评估风险承担方式时，应看两件事：一是发布决策所依据的信息是否充分，二是出问题后的恢复路径是否被验证过。前者决定人工评审有没有价值，后者决定自动化放行是否安全。两者都具备时，把决策交给流水线是合理的；只具备前者时，保留人工发布控制更稳妥。
适用场景：什么团队选持续交付，什么团队选持续部署
选择哪一档，取决于发布频率、合规要求、变更影响面和技术成熟度四个条件的组合，而不是团队规模或行业标签。下面按条件给出判断，团队可对照自身情况定位。
适合以持续交付为主的场景：
- 发布频率不高，例如按周或按双周发布，人工决策的成本可以接受；
- 存在较重的合规或变更评审要求，上线需要留痕、需要责任人签字；
- 生产变更影响面大，涉及资金、权限、核心数据，出错代价高；
- 自动化测试覆盖尚不完整，部分验证依赖人工确认；
- 监控与回滚手段具备，但尚未在真实故障中反复验证。
适合推进持续部署的场景：
- 变更粒度小、提交频繁，人工放行成为交付节奏的瓶颈；
- 核心链路有稳定的自动化测试，回归结果可信；
- 具备灰度发布能力，可按流量比例逐步放量；
- 监控指标、日志与告警能支撑分钟级定位问题；
- 回滚动作经过演练，恢复时间可预期。
多数团队处在两者之间，合理的路径是渐进推进：先把构建、测试、制品产出全部自动化，让任意一次通过校验的变更都处于可发布状态，扩大可发布范围；再针对低风险服务试点自动上线，积累发布记录与回滚数据；确认监控与回滚在真实场景中可靠后，逐步放开更多服务的自动上线。每一步都以证据为依据，而不是以计划进度为依据。
需要暂缓持续部署的条件同样明确：核心服务缺少自动化回归、生产环境没有可用的灰度手段、回滚依赖手工操作且未演练、变更影响面涉及不可逆的数据迁移。这些条件下推进自动上线，等于把未经检验的判断交给流水线执行。
规划发布自动化程度时的落地判断与验证
把上面的差异转成规划动作，第一步是确定起点。看两个现有指标：当前发布频率，以及一次发布失败后的恢复时间。发布频率低且恢复时间长的团队，优先补的是可发布状态和回滚能力，而不是放开自动上线；发布频率已经受人工放行限制、恢复时间在可接受范围内的团队，才具备试点自动上线的条件。
第二步是用试点服务验证。选择变更影响面可控、监控覆盖完整的服务，让它走自动上线流程，观察一个完整周期。验证清单包括：
- 自动上线后，监控能否在约定时间内发现异常；
- 触发回滚后，恢复耗时是否与演练结果一致；
- 发布记录是否完整，能否回溯到具体变更与责任人；
- 变更失败率是否稳定在团队可接受的区间；
- 出现异常时，值班人员能否按预案独立处置。
第三步是记录证据。发布记录、回滚耗时、变更失败率这三类数据是判断能否进入下一档的依据，也是向评审方说明自动化程度合理性的材料。建议在试点前先确定这三项的口径与采集方式，避免试点结束后数据不可比。发布准入规则与质量门禁的具体设计属于另一层工作，本文不展开，但需要提醒：门禁规则应与所选自动化程度匹配，持续部署下的门禁要能替代人工评审所承担的那部分判断。
在管理动作上，发布决策、发布记录与流水线状态需要放在同一处查看，否则人工评审和自动放行都缺少依据。ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，自动同步流水线数据并更新执行状态和日志，同时在项目、迭代、需求中可视化代码提交、流水线构建与产品发布过程，让发布负责人依据完整记录做判断，也让试点阶段的回滚与失败数据可追溯。团队在规划发布自动化程度时，可以借助这类记录把“是否具备下一档条件”从主观判断变成可核对的事实。
常见问题
持续交付模式下保留人工放行，会不会拖慢交付节奏？
是否拖慢取决于人工放行环节实际承担了什么。如果发布负责人只是按固定窗口点一次确认，而校验信息、发布记录、回滚预案都已就绪，这个环节的成本有限，还能保留对高风险变更的判断。真正拖慢节奏的是放行前信息不全、需要临时找人确认、回滚方案没有演练。团队可以先统计每次发布在人工环节停留的时间，如果这部分时间占比高且没有带来对应的风险控制价值，再考虑对低风险服务试点自动上线。
测试覆盖率不高，能否先对部分服务推进持续部署？
可以按服务区分对待，前提是被选中的服务具备可验证的兜底手段。判断标准包括：该服务的核心链路有自动化回归、具备按流量或用户群灰度放量的能力、监控能在约定时间内发现异常、回滚动作经过演练且恢复时间可预期。不满足这些条件的服务，即使变更量小，也建议先停留在持续交付。试点服务的选择应以影响面可控和监控完整为准，不宜按团队意愿或进度压力决定。
持续部署之后，发布审批还需要保留吗？
持续部署取消的是上线前逐次人工放行，审批并没有整体消失，而是以质量门禁的形式固化在流水线里，例如测试通过率、安全扫描结果、变更影响面检查。需要保留人工介入的通常是例外情形：涉及不可逆的数据迁移、影响核心资金或权限的变更、监管要求留痕的发布。团队应明确哪些变更类型必须走人工评审，其余交给门禁判断，避免门禁规则与自动化程度不匹配。
如何判断团队已经具备从持续交付进入持续部署的条件？
用试点服务的实际数据判断，而不是用计划完成度判断。选一个变更影响面可控、监控覆盖完整的服务走自动上线，观察一个完整周期，重点看四项：异常发现时间是否符合约定、回滚耗时是否与演练结果一致、发布记录能否回溯到具体变更与责任人、变更失败率是否稳定在可接受区间。四项都达标，说明工程能力可以承接前移的风险；其中任何一项不达标，应先补齐对应能力再扩大范围。
发布记录和流水线状态分散在不同系统，会影响自动化程度的选择吗？
会影响。人工评审和自动放行都需要依据完整记录做判断，如果发布决策、发布记录与流水线状态分散在不同系统，试点阶段就难以核对回滚耗时和变更失败率，判断“是否具备下一档条件”容易变成主观印象。ONES DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，自动同步流水线数据并更新执行状态和日志，同时在项目、迭代、需求中可视化代码提交、流水线构建与产品发布过程，便于发布负责人依据记录做判断，也让试点数据可追溯。
