持续交付是一种让软件在任意时刻都处于可安全发布状态的工程实践：每次代码变更都经过自动化的构建、测试与部署验证，通过后由人工决定何时发布到生产环境。它关注的是把发布从一次性的大动作拆成随时可执行的小步骤。本文说明持续交付的定义、范围边界、运行机制，并区分它与持续集成、持续部署的差别。
要点总览（TL;DR）
- 持续交付指每次代码变更都经过自动化的构建、测试和部署验证，使软件主干在任意时刻处于可安全发布的状态，发布时机由人工决定。
- 持续交付覆盖构建、自动化测试、类生产环境部署验证和可发布状态维护；流水线与平台对接配置、发布审批与质量门禁规则设计属于相邻主题。
- 运行链路是提交触发构建与测试、制品入库、同一制品依次部署到测试与类生产环境验证，失败即时反馈，发布前准备回滚方案。
- 持续集成、持续交付、持续部署的终点依次是集成验证通过、可发布状态、自动进入生产，人工介入点逐步后移。
- 持续交付不等于天天发布、不等于工具堆叠、不等于取消审批，判断标准是验证可重复、状态可查、发布可随时执行。
持续交付的准确定义
持续交付（Continuous Delivery）指团队通过自动化手段，让每一次代码变更都经过构建、测试和部署验证，使软件主干在任意时刻都处于可安全发布的状态。这里的关键词是“可发布状态”：代码已经通过验证、具备上线条件，至于什么时候真正发布到生产环境，由业务需要和人工决策决定。
判断一个团队是否在实践持续交付，可以观察三个特征：
- 每次提交都能触发一条可重复执行的验证链路，构建和测试结果在较短时间内反馈给提交者，无需人工排队安排。
- 通过验证的版本可以直接部署到类生产环境并完成验证，部署过程有脚本或流水线承载，不依赖某个人的手工操作记忆。
- 发布动作可以在较短时间内完成，且团队对“当前主干能否发布”有明确、可查的结论，而不是临近发布日才集中评估。
这三个特征共同指向一个结果：发布从“项目末期的一次大考”变成“日常可执行的小步骤”。缺少其中任何一条，团队可能在做持续集成，也可能在做自动化部署，但还称不上完整的持续交付。
持续交付包括什么、不包括什么
持续交付覆盖从代码提交到“可发布”之间的验证与准备环节，但不等于把软件自动推上生产，也不涵盖流水线平台本身的对接配置和发布审批规则的设计。下表按环节划出边界。
| 环节 | 是否属于持续交付的核心范围 | 说明 |
|---|---|---|
| 提交触发的自动构建 | 属于 | 每次变更都产出可部署的构建产物，是“随时可发布”的物质基础 |
| 自动化测试（单元、接口、回归等） | 属于 | 用自动化验证替代人工判断变更是否破坏既有功能 |
| 部署到类生产环境并验证 | 属于 | 证明构建产物在接近生产的环境中能正常运行 |
| 维持主干处于可发布状态 | 属于 | 这是持续交付要达成的状态，也是判断是否做到的核心标志 |
| 流水线工具与研发平台的对接配置 | 不属于本文重点 | 属于流水线与平台集成主题，涉及具体工具的参数与权限配置 |
| 发布审批流程与质量门禁规则设计 | 不属于本文重点 | 属于发布管理主题，关注谁在什么条件下批准上线 |
| 自动发布到生产环境 | 不属于持续交付的必要条件 | 持续交付只要求“可发布”，是否自动发布由团队选择，属于持续部署的范畴 |
需要特别说明的是，持续交付与“必须自动发布到生产”是两件事。持续交付的终点是“具备发布条件”，发布动作可以由人按下按钮，也可以按计划自动执行。把持续交付理解为“每次提交都直接上线”，会混淆它与持续部署的界限，也容易让团队在尚未建立足够验证能力时贸然放开生产发布。
持续交付的运行机制与组成
从一次代码提交到形成可发布状态，中间有一条相对固定的链路。理解这条链路，就能理解持续交付在团队中是怎么运转起来的。
提交触发构建与自动化验证
开发者把变更提交到主干或合并请求后，流水线自动启动：拉取代码、安装依赖、编译打包，产出带版本标识的构建产物。随后依次执行单元测试、接口测试和必要的回归测试。任何一步失败，流水线立即停止并向提交者反馈失败位置和日志。反馈越早，修复成本越低，这也是持续交付强调“小步提交”的原因。
制品与环境的一致性管理
通过验证的构建产物会被存入制品库，并以同一份制品依次部署到测试环境和类生产环境。这里的原则是“构建一次、多处部署”：每个环境使用同一个制品，环境差异通过配置注入解决，避免出现“测试环境能跑、生产环境跑不起来”的情况。制品版本与环境配置的对应关系需要可追溯，否则回滚和问题定位都会失去依据。
人工发布决策所处的位置
当制品在类生产环境验证通过，软件就进入可发布状态。此时是否发布、何时发布、发布哪些内容，由产品负责人或发布负责人根据业务节奏决定。持续交付把技术验证自动化，把发布时机留给人的判断，两者分工清晰：自动化负责“能不能发”，人负责“要不要发、什么时候发”。
失败反馈与回滚准备
链路上任何环节失败，都需要有明确的反馈路径：谁收到通知、在哪个工作项上记录、由谁跟进修复。同时，每次发布前应准备好回滚方案，包括上一版本制品是否可用、数据变更是否可逆、回滚由谁执行。回滚能力是持续交付敢以较高频率发布的前提，缺少回滚准备的“快速发布”只是把风险推后。
在这条链路中，需求、任务与代码提交、构建结果的关联是常见的协作断点：验证失败了，但没人清楚它影响哪个需求；某个需求要上线，却说不清对应哪次构建。ONES DevOps 解决方案支持通过业务需求、研发任务等工作项拉取代码分支，并将代码提交与工作项关联，在项目、迭代、需求中可视化代码提交、流水线构建和产品发布过程；集成 Jenkins、GitLab CI 等第三方流水线工具后，可同步流水线执行状态和日志。这类关联让“可发布状态”不只停留在流水线里，也能被需求和项目角色看到，便于在发布决策前确认范围与风险。
持续交付与持续集成、持续部署的区别
三个概念常被混用，区别主要在于各自的终点和人工介入的位置。持续集成解决“代码合进来是否还能正常工作”，持续交付解决“当前版本是否具备发布条件”，持续部署解决“变更是否自动进入生产”。
| 维度 | 持续集成 | 持续交付 | 持续部署 |
|---|---|---|---|
| 终点 | 集成验证通过，主干保持可用 | 版本通过验证，处于可发布状态 | 变更自动进入生产环境并生效 |
| 自动化程度 | 构建与测试自动化 | 构建、测试、部署验证自动化 | 在持续交付基础上，生产发布也自动化 |
| 人工介入点 | 开发者处理集成失败 | 由人决定是否发布、何时发布 | 人工介入主要在异常处理和发布策略设定 |
| 对验证能力的要求 | 具备自动化测试即可 | 需要类生产环境验证与回滚准备 | 需要更强的监控、灰度与自动回滚能力 |
三者是递进关系而非替代关系：持续集成是基础，持续交付在其上增加部署验证和可发布状态的管理，持续部署再把发布决策也交给自动化。团队可以从持续集成起步，验证能力成熟后再推进到持续交付；是否进一步走向持续部署，取决于业务对发布风险的承受能力和监控水平。
一个具体例子与常见误解
以下为演示性场景，用于说明持续交付的落地形态，不指向任何真实团队或数据。
从提交到可发布的完整小例子
某团队开发一个订单功能。开发者完成“订单取消”需求的代码后提交合并请求，流水线自动构建并运行单元测试与接口测试，全部通过后制品入库，版本号标记为本次构建。随后流水线把该制品部署到测试环境，自动化回归用例覆盖下单、支付、取消等主流程，结果通过；再部署到类生产环境，由测试人员做一轮冒烟验证。此时该版本进入可发布状态，需求工作项上可以看到关联的提交记录和构建结果。发布负责人根据本周业务安排，决定周四晚将该版本发布到生产，发布前确认回滚方案可用。整个过程没有集中式的“发布冲刺”，发布只是从可发布版本中挑一个时间点执行。
常见误解澄清
- 误解一：持续交付等于天天发布。持续交付要求随时可发布，实际发布频率由业务需要决定。一个季度发布一次的产品，同样可以实践持续交付，只要每次发布前不需要长时间集中测试和手工准备。
- 误解二：持续交付等于工具堆叠。流水线工具、测试框架、制品库是承载手段，持续交付的核心是让验证可重复、状态可判断。工具齐全但验证用例覆盖不足、失败无人处理的团队，并没有真正做到持续交付。
- 误解三：持续交付等于取消审批。持续交付自动化的是技术验证，发布审批作为业务决策环节可以保留。审批关注的是发布范围、时机和风险，验证关注的是版本质量，两者承担不同职责。
- 误解四：持续交付只与开发和运维有关。可发布状态的判断依赖需求范围是否清晰、验收标准是否明确。需求侧信息缺失时，流水线再顺畅也无法回答“这个版本能不能发”。
这些误解的共同来源，是把持续交付的某个手段或某个结果当成了定义本身。回到定义：持续交付是一种让软件随时处于可安全发布状态的实践，判断标准是验证是否可重复、状态是否可查、发布是否可随时执行，而不是发布频率高低或工具数量多少。
常见问题
团队规模较小、发布频率不高，还有必要实践持续交付吗？
有必要，但推进节奏可以放缓。持续交付要解决的是“发布前是否需要长时间集中测试和手工准备”，与发布频率无关。发布频率低的团队同样可以先做到每次提交自动构建和跑核心自动化测试，再逐步补上类生产环境验证和回滚方案。判断是否值得投入的标准是：每次发布前的准备工作是否占用大量人力、是否经常出现环境差异导致的问题。如果这两点明显，持续交付的收益就成立。
已经有一条能自动构建和跑测试的流水线，算不算做到了持续交付？
还需要看两个条件。一是通过验证的制品能否以同一份产物部署到类生产环境并完成验证，证明它具备上线条件；二是团队对“当前主干能否发布”是否有明确、可查的结论。只有构建和测试，通常停留在持续集成阶段。补齐部署验证和可发布状态的记录，才构成完整的持续交付链路。
保留发布审批会不会与持续交付冲突？
不冲突，两者职责不同。持续交付自动化的是技术验证，回答“这个版本能不能发”；发布审批是业务决策，回答“这次发什么、什么时候发、风险是否可接受”。审批环节可以保留，但审批所依据的信息应当来自可查的验证结果和变更范围，避免审批变成重新做一遍人工测试。若审批长期依赖发布前集中回归，说明验证能力还没有真正前移。
验证失败后，如何避免“构建红了没人管”？
关键是把失败反馈落到具体的人和具体的工作项上。流水线失败时应通知提交者，并在对应的需求或任务上留下记录，明确谁跟进修复、修复期限如何约定。团队可以把“主干保持可发布”作为日常约定：失败未修复前优先处理，暂缓合入新的变更。反馈路径清晰、责任到人，比增加更多流水线环节更有效。
需求、任务与代码提交、构建结果之间如何保持关联？
常见做法是通过工作项拉取代码分支，并在提交信息中关联工作项编号，让提交记录、构建结果和需求形成可追溯的链条。ONES DevOps 解决方案支持通过业务需求、研发任务等工作项拉取代码分支，并将代码提交与工作项关联，在项目、迭代、需求中可视化代码提交、流水线构建和产品发布过程；集成 Jenkins、GitLab CI 等第三方流水线工具后，可同步流水线执行状态和日志。这样在发布决策前，需求范围和验证结果可以在同一处确认。
