持续交付与持续部署：发布控制、风险与适用场景区别

持续交付与持续部署常被放在一起讨论，真正的分界点在“生产发布”这一步：持续交付让每次变更都处于可随时发布的状态，发布动作由人按业务节奏决定；持续部署则让通过验证的变更自动进入生产。团队规划发布自动化程度时，需要围绕发布控制权、风险落点和自身验证成熟度来判断，而不是只看流水线跑得多快。下文用同一套维度对照两种模式，并说明从持续交付走向持续部署需要补齐的前提；发布决策的审批与结果留痕，可由协作工具承载。

要点总览（TL;DR）

• 两者的分界点在“生产发布”这一步：持续交付的终点是变更处于可随时发布状态，持续部署的终点是变更已自动发布到生产。
• 发布控制上，持续交付由发布或业务负责人决定是否发布、何时发布，放行依据是机器验证加人工判断；持续部署由流水线规则自动放行，依据收敛为可自动判定的验证结果。
• 风险随控制权转移：持续交付集中在人工发布判断与发布窗口拥挤，责任在发布负责人；持续部署集中在验证覆盖不足与故障发现速度，责任在测试、SRE 与流水线维护者。
• 适用场景按发布频率、变更粒度、验证与监控成熟度、合规审批要求四项条件判断，验证与监控成熟度最关键，实际选择常按服务或变更类型混合使用。
• 从持续交付走向持续部署，需依次补齐验证与可观测性、引入灰度放量、常态化回滚演练，再逐步放开自动发布，并用发布失败率、回滚次数等指标判断能否进入下一阶段。

同一交付流里，两者的分界点在哪里

把一次变更从提交到上线铺开，可以看到两种模式共享绝大部分环节，差异只出现在最后一段。可以用下面这条主线定位：

提交代码 → 构建 → 自动化测试 → 部署到预发/测试环境 → 生产发布（分界点） → 线上验证与监控

在分界点之前，持续交付与持续部署的要求基本一致：代码提交要能触发构建，构建产物要可追踪，测试要能自动执行并给出结果，预发环境要能稳定复现生产配置。这些前置自动化能力是两种模式共同的底座，缺少任何一项，讨论“要不要自动发布”都没有意义。

分界点之后，两者走向不同：

• 持续交付的终点是“可发布”。流水线把变更送到生产门口，产出一个经过验证、可以随时上线的版本，是否推开这扇门由人决定。
• 持续部署的终点是“已发布”。流水线在验证通过后直接完成生产发布，人不再逐次确认，发布成为流水线的最后一个自动步骤。

一句话对照：持续交付回答“这个版本能不能发”，持续部署回答“这个版本已经发了”。两者的构建、测试、预发部署环节可以完全相同，差别在于生产发布这一步由谁按下确认。

发布控制：人工放行与自动放行的差别

发布控制的差异可以从三个要素看清：谁做决定、依据什么放行、出问题时谁触发回滚。这三个要素决定了团队对生产变更的实际掌控方式。

控制要素	持续交付	持续部署
发布决策权	由发布负责人或业务负责人决定是否发布、何时发布	由流水线规则决定，验证通过即自动发布
放行依据	自动化验证结果，叠加发布窗口、变更评审、业务节奏等人工判断	以自动化验证结果为主，包括测试通过率、质量门禁、灰度指标
回滚触发	由发布负责人根据线上表现决定是否回滚，时点由人选择	由监控告警或流水线规则自动触发，也可保留人工介入通道

持续交付把发布决策权留在团队手里，放行依据是“机器验证 + 人的业务判断”。这种组合适合发布需要配合运营活动、客户通知或合规窗口的场景，人可以在最后一刻叫停。代价是每次发布都需要有人值守和确认，发布节奏受人力安排影响。

持续部署把决策权交给流水线规则，放行依据收敛为可自动判定的验证结果。发布不再依赖某个人在场，节奏由变更本身驱动。这要求验证规则足够明确：哪些测试必须通过、哪些指标超过阈值就阻断、灰度阶段观察到什么信号就回滚，都要提前写成流水线能执行的判断，而不是留在人的经验里。

回滚触发方式的差别同样重要。持续交付的回滚通常由人判断时点，反应速度取决于值班响应；持续部署的回滚更多依赖监控与规则自动执行，反应速度取决于告警配置和回滚脚本的可靠性。两种方式都可以保留人工兜底，区别在于默认路径是人工还是自动。

风险承担：风险落在哪一环、由谁承担

控制权放在哪里，风险就集中在哪里。两种模式并不消除风险，而是把风险转移到不同环节、交给不同角色承担。

持续交付的风险集中在人工发布判断与发布窗口拥挤。发布负责人需要在有限信息下判断“这次能不能发”，判断失误的责任落在这个角色身上。当多个变更排队等待同一个发布窗口时，窗口内堆积的变更数量增加，一旦出问题，排查范围变大，回滚也更复杂。对应的兜底手段是明确的发布检查清单、发布前评审，以及发布窗口的数量控制。

持续部署的风险集中在验证覆盖不足与故障发现速度。自动放行意味着没有人再逐次把关，如果测试覆盖不到某类变更，或者监控没有覆盖关键指标，问题会直接进入生产。责任从“某个人拍板”转移到“验证规则与监控体系的设计者”，包括测试负责人、SRE 和流水线维护者。对应的兜底手段是灰度发布、按比例放量、关键指标告警和可快速执行的回滚。

风险维度	持续交付	持续部署
风险集中环节	人工发布判断、发布窗口内的变更堆积	自动化验证覆盖度、线上故障发现与恢复速度
主要责任角色	发布负责人、业务负责人	测试与质量负责人、SRE、流水线维护者
典型兜底手段	发布检查清单、发布前评审、控制单窗口变更量	灰度发布、指标告警、自动回滚、发布后校验

判断自身风险承受结构时，可以问两个问题：团队是否有人能稳定承担逐次发布判断的责任；验证与监控体系是否能在无人确认的情况下及时发现异常。前者决定持续交付能否运转，后者决定持续部署能否安全运转。

适用场景：按发布频率、变更粒度与验证成熟度判断

选择哪种模式，取决于团队当前的发布节奏和工程成熟度，而不是哪种做法更先进。可以按下面四项条件逐条对照。

判断条件	倾向持续交付	倾向持续部署
发布频率与业务节奏	发布频率较低，或发布需配合运营活动、客户通知	发布频繁，变更随开发完成自然上线
变更粒度与影响面	单次变更影响面大，涉及多个模块或数据结构调整	变更粒度小、彼此独立，单次影响范围可控
验证与监控成熟度	自动化测试覆盖有限，线上监控以基础指标为主	关键路径测试覆盖充分，监控与告警能覆盖核心业务指标
合规与审批要求	存在发布审批、变更评审或留痕要求	审批可通过自动化门禁表达，无需逐次人工签字

四项条件中，验证与监控成熟度是最关键的一项。发布频率低但验证薄弱的团队，贸然自动发布只会把问题更快送进生产；验证充分但审批要求严格的团队，可以把人工确认保留在合规环节，其余变更走自动发布。

实际选择常常是混合的：核心交易链路采用持续交付，保留人工放行；内部工具、配置类变更采用持续部署。团队可以按服务或变更类型分别设定自动化程度，不必对整个系统做统一选择。

从持续交付走向持续部署的过渡条件

已经稳定运行持续交付的团队，提升自动化程度需要按顺序补齐前提，而不是直接关掉人工确认。可以按以下阶段推进。

第一阶段：补齐验证与可观测性。梳理核心业务链路的自动化测试覆盖，确认关键路径有测试保护；为生产环境配置能反映业务健康的监控指标和告警规则。完成标志是：一次典型变更出问题时，监控能在可接受时间内发出告警。

第二阶段：引入中间形态。在完全自动发布之前，先采用灰度发布或按比例放量：新版本先进入小比例流量，观察指标后再扩大范围。这一阶段仍保留人工确认扩大放量的动作，但发布本身已由流水线执行。完成标志是：灰度阶段的指标判断有明确标准，且能稳定执行。

第三阶段：常态化回滚演练与发布后校验。定期演练回滚流程，确认回滚脚本可用、耗时可控；把发布后校验写成固定步骤，包括关键接口检查与指标比对。完成标志是：回滚演练有记录，实际回滚耗时符合预期。

第四阶段：放开自动发布。在前三阶段稳定运行后，选择变更粒度小、影响面可控的服务先行自动发布，逐步扩大范围。保留人工介入通道，用于异常情况下的紧急停止。

每个阶段都应设定观察期，用发布失败率、回滚次数、故障恢复时长等指标判断是否可以进入下一阶段。指标没有改善时，停留在当前阶段是合理选择。

发布决策在协作工具中的落地方式

无论采用哪种模式，发布决策都需要留下可追溯的记录：发布了什么、依据哪些验证结果放行、谁确认的、结果如何、是否回滚。这些记录让风险责任有据可查，也为后续复盘提供输入。

落地时可以用发布单或变更单承载以下字段：

• 发布范围：关联的需求、工作项与代码变更，明确本次发布包含哪些内容；
• 验证结果：测试通过情况、质量门禁结果、灰度阶段指标，作为放行依据；
• 放行记录：审批人、审批时间、审批意见，人工放行与自动放行分别记录；
• 发布结果与回滚记录：发布时间、发布状态、是否回滚、回滚原因，回写到对应工作项。

ONES 的 DevOps 解决方案可以在这条链路上提供承载：集成 Jenkins、GitLab CI 等第三方流水线工具后，ONES 会自动同步流水线数据并更新执行状态和日志；在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等 CI/CD 过程，帮助团队追踪研发过程。发布单关联的需求与代码变更可以在同一工作项下查看，发布结果回写后形成从需求到上线的追溯链路。对于需要保留人工放行的持续交付场景，审批记录与验证结果一并留存在发布单上；对于持续部署场景，流水线执行状态与发布结果自动同步，减少人工补录。

把发布决策管理起来的关键，是让“依据什么放行”和“发布后发生了什么”都能在同一处查到。工具承载的是记录与追溯，放行规则本身仍需团队根据验证成熟度来设定。

常见问题

团队已经能稳定做持续交付，可以直接关掉人工确认改成持续部署吗？

不建议直接切换。人工确认是当前唯一的最后一道拦截，关掉之前需要先确认两件事：核心业务链路的自动化测试能否覆盖典型变更，生产监控能否在可接受时间内发现异常。这两项没有稳定运行之前，自动发布只会让问题更快进入生产。更稳妥的路径是先引入灰度发布或按比例放量，保留人工确认扩大放量的动作，等灰度阶段的指标判断有明确标准并能稳定执行后，再选择变更粒度小、影响面可控的服务先行自动发布。

发布频率很低，是否就没有必要区分持续交付和持续部署？

仍然需要区分，因为两者的差别不在频率高低，而在发布决策由谁做出。发布频率低的团队通常更适合持续交付：变更影响面可能较大，发布需要配合运营活动或客户通知，保留人工放行更符合实际。区分两者的意义在于明确发布控制权归属和风险落点，避免团队在验证体系尚不成熟时误以为“流水线跑通了就等于可以自动发布”。

合规审批要求严格的团队，是否只能停留在持续交付？

不一定。可以把人工确认保留在合规环节，其余变更走自动发布。具体做法是把审批要求表达为流水线可执行的质量门禁，例如必须通过的测试项、必须留存的评审记录，让审批结果成为放行依据的一部分，而不是每次发布都重新走一遍人工签字。核心交易链路保留人工放行、内部工具与配置类变更自动发布，是常见的混合方式。

自动发布后出问题，回滚应该由人触发还是由系统触发？

两种都可以，区别在默认路径。持续部署场景下，回滚更多依赖监控告警或流水线规则自动触发，反应速度取决于告警配置和回滚脚本的可靠性，同时应保留人工介入通道用于紧急停止。无论默认路径是哪种，回滚流程都需要定期演练，确认脚本可用、耗时可控，否则自动触发的规则在真实故障中未必能按预期执行。

发布单上需要记录哪些内容，才能支撑后续复盘？

至少覆盖四类信息：发布范围，即关联的需求、工作项与代码变更；验证结果，包括测试通过情况、质量门禁结果和灰度阶段指标；放行记录，即审批人、审批时间与审批意见，人工放行与自动放行分别记录；发布结果与回滚记录，包括发布时间、发布状态、是否回滚及原因。这些记录回写到对应工作项后，才能形成从需求到上线的追溯链路。ONES 的 DevOps 解决方案可集成 Jenkins、GitLab CI 等第三方流水线工具，自动同步流水线数据并更新执行状态和日志，并在项目、迭代、需求中可视化代码提交、流水线构建、产品发布等 CI/CD 过程。