11.2 交付流水线
概述与动机
交付流水线是把一个经过验证的想法，转化为用户手中可运行软件（可靠地、可重复地、可度量地）的工作流程，然后把由此产生的结果数据反馈回发现流程（第 11.1 章）。它是从一次代码提交，到一次生产环境变更，再到对用户和业务产生一个可度量效果的工业化路径。发现回答的是做什么、为什么做，而交付回答的是我们如何安全地交付它、交付得有多快，以及它究竟有没有奏效。
本章刻意采用整合的视角。具体机制在别处有详细讨论：测试策略（第 2.4 章）、测试与流程自动化（第 8.5 章）、持续集成与持续交付（CI/CD）以及部署策略（第 8.1 章）、基础设施即代码（第 8.2 章）、可靠性与 SLO（服务水平目标，第 9.1 章），以及实验（第 7.4 章）。在本章，我们把这些拼装成一条端到端的流水线，并且（）至关重要的是（）为它附加上能告诉你整台机器究竟是在产生价值、还是仅仅在产生发布这一事实的结果指标。
对大型团队而言，交付流水线是工程效能领域杠杆最高的单一投资。十年来的研究（）最突出的是 Accelerate 一书所总结的 DORA（DevOps 研究与评估）项目（）表明，拥有快速、自动化、低风险交付流水线的团队，在吞吐量和稳定性以及组织成果上都表现更优。那种认为速度与安全必然此消彼长的旧观念，在实证上是错误的。在企业中，一条强健的流水线正是让数百名工程师得以集成代码、而不至于陷入合并混乱和人工发布表演的原因。在政府场景中，它取代了高仪式感、按季度进行、要么全上要么全不上的”大爆炸式”发布（历史上导致项目失败的一大主因），代之以小规模、可逆、可审计的变更，让变更控制义务是通过自动化来满足，而不是尽管有自动化却仍要靠人力去满足。
关键原则
- 把一切可重复的事情自动化。 人工步骤缓慢、易出错，也无法审计。
- 小批量、高频次发布。 小的变更更容易评审、测试、发布和撤销。
- 把质量内建进去。 快速、自动化的测试和门禁在问题进入生产环境之前就捕捉到它，而不是之后。
- 把部署和发布分开。 先把代码暗中上线，准备好后再用开关打开功能。
- 让一切都可逆。 快速回滚和渐进式暴露，把部署从一场赌博变成一场实验。
- 流水线就是权威数据源。 如果一件事没有进入版本控制和流水线，就等于没有发生过。
- 度量结果，而不仅仅是产出。 部署次数是一种产出；被推动的指标才是一种结果。
建议
把测试套件自动化，并以它作为门禁
测试自动化是让快速交付变得安全的基础。实施一套均衡、大部分自动化的测试组合（第 2.4 章）：大量快速的单元测试、较少的集成测试和契约测试、少量端到端测试，再加上自动化的安全检查（SAST/DAST/SCA：静态、动态和软件成分分析）、无障碍检查和性能检查。把它们作为流水线中的质量门禁来运行，使任何变更未通过就无法进入生产环境。保持这套测试套件快速且值得信赖：一套缓慢或不稳定的测试套件会被人绕过，这就违背了它存在的初衷（第 8.5 章）。力求让流水线在一次提交之后的几分钟内，就给开发者一个清晰的通过／失败信号。
践行持续集成与持续交付
持续集成（continuous integration，CI）： 每位开发者频繁地（理想情况下每天）把小的变更合并进主线，每一次合并都会触发一次自动化的构建和测试运行。这一点最好由主干开发（第 2.6 章）来支撑，它让分支保持短命、集成保持连续。持续交付（continuous delivery，CD）： 每一个通过流水线的变更都始终处于可发布状态，可以按需部署。持续部署（continuous deployment）则更进一步：每一个通过的变更都会自动部署到生产环境。要根据你的风险状况来选择合适的自动化程度；受监管的环境可能止步于持续交付、再加一个受控的晋级步骤（第 8.1 章），但在到达那道门禁之前的一切，仍然应当全部自动化。
用渐进式策略安全地部署
把部署（deployment，代码在生产环境中运行）与发布（release，用户体验到变化）解耦，让变更逐步曝光：
- 功能开关（feature flag）让你能暗中部署代码，按需向特定用户群发布，并可以通过切换开关立即回滚。
- 金丝雀发布（canary release）把一小部分流量导向新版本，在扩大范围之前先观察健康指标。
- 蓝绿部署（blue-green deployment）保留两套环境，原子式地切换流量，可即时回滚。
- 滚动部署（rolling deployment）逐步替换各个实例。
- 渐进式交付（progressive delivery）结合开关、金丝雀和自动化分析，依据实时信号来推进或回滚。
为每一种策略都配上由 SLO 违约或错误预算消耗（失败消耗允许的不可靠性预算的速率；第 9.1 章）触发的自动回滚。具体机制参见第 8.1 章。
为结果指标埋点：既要度量流水线，也要度量影响
一条交付很快、却交付了错误东西的流水线，只是快速的浪费。要在三个层面进行度量：
交付流动性，四项 DORA 指标：
可靠性与质量，SLI 与 SLO（服务水平指标与服务水平目标；第 9.1 章）：每次变更之后，该服务是否仍满足其可靠性目标和质量属性承诺（第 11.1 章）？
业务与用户结果（第 7.3 至 7.4 章）：这次变更是否推动了发现阶段所定义的关键结果和 KPI？这正是发布与实验相遇之处：先在开关背后发布，与对照组进行度量对比，只保留胜出的那一部分。
把闭环连回发现流程
交付流水线的最终动作不是部署，而是证据。结果指标（激活率是否上升、结账时间是否缩短、支持工单是否减少）会流回发现流水线（第 11.1 章），成为下一轮投入决策的依据。当发现与交付被这个反馈闭环连接起来时，整个组织就变成了一个学习系统：假设被交付、被度量，然后要么被放大、要么被撤回，持续不断地循环。
让交付变得可审计、受治理
在企业和政府场景中，要把流水线本身当作一项合规控制来对待。由于每一次变更都流经版本控制和一条自动化流水线，你”免费”获得了一条不可篡改的审计轨迹：谁改了什么、哪些测试和审批为其把关、以及它何时部署。把职责分离、强制评审和策略检查编码为策略即代码（policy as code，以机器可执行、受版本控制的形式表达的治理规则；第 8.2 章），这样变更控制就会被自动强制执行，并被持续留下证据（第 4.6 章与第 10.2 章），而不是在审计前才手忙脚乱地手工拼凑。
权衡：利与弊
| 决策 | 优点 | 缺点 |
|---|---|---|
| 持续部署（自动上生产） | 反馈最快；批量最小；人工劳动最少 | 要求成熟的测试、监控、回滚能力；在受监管的门禁环境下较难实现 |
| 持续交付配人工晋级 | 有人工／合规控制点；对审计友好 | 更慢；变更可能在门禁处被积压成批 |
| 功能开关 | 部署与发布分离；即时回滚；可定向发布 | 若不清理，会产生开关债务和组合爆炸式的复杂度 |
| 金丝雀／渐进式交付 | 限制爆炸半径；由数据驱动晋级 | 需要强大的可观测性和流量管理能力 |
| 蓝绿部署 | 即时切换与回滚 | 环境成本翻倍；有状态／数据迁移比较棘手 |
| 繁重的人工发布流程 | 给人可控的感觉；审计人员熟悉 | 缓慢、易出错、不可重现，实践中也难以真正被审计 |
那种历史上流传的权衡观念（）跑得更快，出的问题就会更多（）正是最需要被抛弃的一条。证据显示，那些能提高速度的实践（自动化、小批量、快速测试、可逆性），恰恰同样是能提高稳定性的实践。真正的权衡在于投资力度与控制粒度，而不是速度与安全之间的取舍。
需要与团队讨论的问题
你们真实的风险状况是什么，它能否证明止步于持续交付、而不迈向持续部署是合理的？ 选择自动化程度是一个真实的决策，而不是一个默认设置。持续部署带来最快的反馈和最小的批量，但它要求成熟的测试、强大的可观测性和即时回滚能力，因此一个受监管的场景止步于一道受控的晋级门禁，可能是理性的选择。带上证据：你的变更失败率、恢复时间，以及你测试套件的可信程度，因为这些能告诉你今天自动上生产是否安全。对企业和政府而言，把到门禁之前的一切都自动化，并把门禁本身也做成策略即代码，这样人工步骤增加的是控制力，而不是人工劳动。如果你还不能信任流水线会拦下一个糟糕的变更，那就先投资于门禁和可观测性，再去扳动那个开关。
你们的流水线能否在无人手工拼凑的情况下，产出一份监管者会要求查看的审计证据？ 把流水线本身当作一项合规控制来对待。每一次变更都应当自动生成一条不可篡改的轨迹：谁改了什么、哪些测试和审批为其把关、以及它何时部署。在企业和政府场景中，把职责分离和强制评审编码为策略即代码，这样变更控制就会被持续强制执行并留下证据，而不是在审计前的恐慌中临时拼凑。可以带来的信号是：挑一次最近的生产环境变更，试着在五分钟内拿出它完整的审批与测试轨迹。如果做不到，你正在为人工审计准备工作付费，并承担着本可由自动化消除的风险。
当一次发布在生产环境中开始退化时，是什么触发了回滚，它是自动的吗？ 可逆性正是让速度显得理性、而不是鲁莽的原因，所以回滚触发条件值得被明确设计。要决定的是：SLO 违约或错误预算消耗是否会自动触发回滚，还是必须等一个人先注意到、再做出决定、再采取行动，而用户在此期间一直在承受影响。带上最近的几次事故，测量一下”指标开始退化”与”变更被撤销”之间的间隔；那个间隔就是你真实的爆炸半径。对于每天发布多次的大型团队而言，人工回滚无法扩展，而功能开关加上金丝雀分析，能让你依据实时信号来推进或撤回。如果你的答案是”有人会被呼叫、然后自己想办法”，那你就是在把每一次部署都当作一次不可逆的赌注。
当你交付一个功能时，你们会去度量它是否真的推动了它本该推动的那个指标，还是仅仅数一数部署次数就算完事？ 一条交付很快、却从不核实影响的流水线，只是快速的浪费，而产出与结果之间的落差，正是大多数交付投资悄悄流失的地方。对一个大型组织而言，一周数百次发布很容易让人把部署频率当作记分牌，然而频率度量的是动作，不是价值；相互竞争的拉力在于，度量结果需要埋点、需要一个对照组，也需要有纪律把一个失败的功能保持在关闭状态。带上最近交付的几个功能，对每一个都说清楚：发现阶段定义的目标指标是什么、前后实际测得的数据是什么，以及当它没有起作用时你们做了什么。在企业和政府的项目组合中，指明谁按固定节奏复核结果、谁有权下线一个已经上线却从未带来回报的功能，因为一个没有人负责度量的变更，就是一个永远不会被关闭的变更。诚实的检验标准是：你能否举出一个因为证据表明它失败了而被你们撤回的功能。
你的流水线需要多久才能给开发者一个通过／失败的信号，他们对这些测试的信任程度是否足以让他们不去绕开它？ 反馈速度和对测试套件的信任，正是让质量门禁真正起到门禁作用、而不是被绕过的关键，而这两者都会随着代码库的增长而悄悄侵蚀。对一个大型团队而言，一套耗时四十分钟、或十次运行里有一次不稳定的测试套件，会训练出成百上千名工程师带着红色状态合并、关闭检查，或者反复重跑直到变绿，这悄悄拿走了当初支撑”跑得快”这一决定的那份安全感；相互竞争的考量是测试覆盖率与真实度，对上反馈速度与稳定性，任何一方被推得太过，都会削弱另一方。带上当前的流水线耗时、不稳定重跑的比率，以及任何门禁被跳过或被标记为非阻塞的证据。对于那些门禁还承载着满足合规要求的 SAST、DAST 和策略检查的企业与政府场景，一个被绕过的门禁既是质量风险，也是审计缺口，因此要衡量这道门禁究竟是真正强制的，还是仅仅是建议性的。如果开发者说不清楚他们为什么信任一次绿色构建，这道门禁就只是装饰。
谁负责让交付路径在各团队之间保持一致、并清理功能开关债务，还是每个团队都在各自重新发明自己的流水线？ 随着组织的成长，交付要么收敛到一条共享的标准化通路上，要么碎裂成几十条各自为政的流水线，带着不兼容的门禁、参差不齐的审计轨迹，以及早已失去存在意义却仍在的开关。这里的张力是真实的：一条中心化的标准化通路能给你一致性、治理能力和规模经济，但一项忽视了某个团队真实约束的强制规定，会催生影子流水线和抵触情绪，因此这条标准化通路必须足够好，好到团队愿意自愿采用。带上一份清单，说明今天究竟存在多少条不同的流水线、开关的创建与移除是如何治理的，以及你们最好和最差的团队之间，前置时间和审计质量的差距有多大。在企业和政府场景中，再加上合规这个角度：不一致的流水线意味着职责分离和变更控制的证据在每个团队里各不相同（甚至根本不存在），而一条经过审计、以策略即代码实现的统一标准化通路，能把这从一个逐团队的赌博变成一项组织层面的保证。如果没有人负责清理过期的开关，组合式的债务终将让这个系统变得无法测试。
行业视角
初创公司。 速度就是生存，所以要买来你的流水线，而不是自己造一条：把主干开发接到一个托管的 CI 运行器上，让每一次合并都以快速单元测试和一次安全扫描作为门禁，并让通过的构建直接部署到生产环境、藏在一个托管的功能开关服务背后。跳过平台团队和定制化工具；你最稀缺的资源是工程注意力，一条单个通才工程师就能维护的流水线，胜过一条没人有时间修的精致流水线。从第一天起就在一个简单的仪表盘上追踪四项 DORA 指标，这样你能尽早了解自己的流动状况，也能向投资人证明你们每天都在发布、却没有把系统搞坏。
小型企业。 由于没有专职的发布工程师，预算也紧张，要把交付当作从托管服务中拼装出来的东西，而不是一个需要专人维护的系统：托管的 CI/CD、一个托管的开关工具，以及一个能替你处理上线和回滚的云平台。抵制住自己搭建养不起的定制流水线基础设施的冲动，让这条路径简单到值班人员在压力之下也能看懂。优先选择那些开箱即用就能提供渐进式交付和一键回滚的工具，因为正是这些能力，把一个令人心惊的周五部署变成一件寻常小事。
企业。 核心问题是众多团队之间的一致性：一条被支持的标准化流水线，带有自动化的测试、安全和策略即代码门禁，供各团队自愿采用，而不是各自重新发明。把接口标准化，使 DORA 和 SLO 指标能在全组织范围内可比；为维护这条标准化通路的平台能力明确地编列预算；把功能开关和前置时间的退化当作受治理的资产来管理，而不是任其成为各团队各自的口口相传。当每一次变更都流经同一条受版本控制、有门禁的路径时，治理和审计就会自动附带而来。
政府。 采购规则、透明度和公共问责塑造了这条流水线，因此要偏向那种止步于一道自动化晋级门禁、以策略即代码强制职责分离和必需审批的持续交付。把流水线本身变成合规控制：每一次变更都自带一条不可篡改的审计轨迹，满足变更控制和运营授权（ATO）义务，而无需事后手工重建。用小规模、可逆、解耦的变更取代高仪式感的”大爆炸式”发布，这样你就能在一个地区先试点一条面向公众的流程，度量错误率和完成率，一旦出现退化，也能在几分钟内回滚。
示例
初创公司。 一个三人工程团队为一款 B2B 分析工具提供服务，一开始是在周五下午手工部署，这意味着每周一次令人心惊的发布，以及一个提心吊胆的周末。他们用一个下午的时间，把主干开发接到一条 GitHub Actions 流水线上：快速单元测试、一个代码检查器和一次安全扫描为每一次合并把关，通过的构建会直接部署到生产环境，藏在 LaunchDarkly 的开关背后。部署频率从每周一次跃升到每天数次，而且由于每个新功能都是暗中上线、先向一位友好的客户开放，一个损坏的 CSV 导出功能能在几分钟内被发现并被关闭，而不是变成周一的一起事故。他们在一个简单的仪表盘上追踪四项 DORA 指标，以便向投资人展示团队每天都在发布、却没有把系统搞坏。
企业。 一家全球性保险公司把 40 个团队整合到一条共享的标准化流水线上（一条被支持的、预先集成好、供团队自愿采用的默认工具链；第 8.4 章）：主干开发、自动化的测试和安全门禁，以及带有 SLO 违约自动回滚的金丝雀部署。部署频率从每月一次上升到每天多次；前置时间从六周降到不足一天；由于批量小、门禁又是自动化的，变更失败率随之下降。至关重要的是，产品功能现在都是在开关背后发布、并与对照组进行度量比较，因此这家保险公司能把每一次发布与它对报价完成率的影响直接挂钩，把交付流水线直接与第 11.1 章发现侧的关键结果连接起来。
政府。 一个公共机构把每季度一次的”大爆炸式”发布（每一次都是一个周末的人工步骤，也是频发故障的一大来源）替换成一条止步于一道自动化晋级门禁的持续交付流水线，这道门禁以策略即代码的形式强制职责分离和必需审批。每一次变更都自带一条不可篡改的审计轨迹，满足该机构的变更控制和 ATO（运营授权）义务（第 4.6 章）。发布变得小规模、高频次、可逆；恢复时间从数天降到几分钟；而且由于部署通过开关与发布解耦，该机构得以先在一个地区试点一条新的福利申领流程，再全国推广，在承诺之前先度量完成率和错误率。
商业理由：动机、投资回报率与总拥有成本
对交付流水线的投资，是软件领域证据最充分的回报之一。更短的前置时间和更高的部署频率，意味着想法能更快抵达用户手中（并更快开始产生价值，或被更快纠正）。更低的变更失败率和更快的恢复速度，意味着更少的停机、更少的救火，以及更少的声誉和监管损害。DORA 的研究把这些能力与更优秀的商业和组织绩效联系在一起，而不仅仅是工程上的舒适感。复合效应很关键：一个每天都在交付、都在学习的团队，其迭代速度是每月才交付一次的团队的 20 到 30 倍，这种学习速率在产品的整个生命周期中具有决定性意义。
在总拥有成本方面，自动化把成本从永无止境的人工劳动，转移到一次性投入外加持续维护的流水线投资上。一次人工发布每一次都要消耗资深工程师的时间，扩展性差，产出的审计证据也很薄弱。一条自动化流水线会把这份成本摊销掉，随着量的增长而降低成本，同时还能持续产出更有力的证据。可逆性降低了失败本身的代价：当任何变更都能在几秒钟内回滚时，一次糟糕部署的预期成本就会大幅下降，这正是让”跑得快”显得理性、而非鲁莽的原因。
要向领导层阐明这一理由，先用四项 DORA 指标和每次发布所耗费的人工工时来度量当前的基线，再量化被移除的人工劳动和被避免的停机时间。采纳这套流水线的成本是真实的，也就是流水线工程、测试投入，以及一项平台／标准化通路能力（第 8.4 章）；但不投资的代价，会以缓慢的反馈、发布日的风险、工程师的职业倦怠和审计的痛苦，持续不断地被支付。最有说服力的论据是与发现流程的连接：一条快速、有度量的交付流水线，正是让发现流水线中经过验证的投入决策真正能在生产环境中被检验的原因。
反模式与陷阱
- 度量产出而非结果： 一边为部署数量欢呼，一边任由目标指标原地不动。
- 缓慢或不稳定的测试套件： 门禁变成开发者学会去无视或绕过的东西。
- 大爆炸式、低频次的发布： 大批量变更风险高、难以调试，也难以撤销。
- 部署与发布混为一谈： 没有功能开关，于是每一次部署都是一次不可逆的、直接面向用户的赌注。
- 人工发布表演： 靠人手工执行的检查清单，缓慢、不一致，也难以真正被审计。
- 自动化流水线却没有可观测性： 交付得很快，却没有能力去检测或诊断回归问题。
- 功能开关债务： 开关从不被移除，累积成无法测试的组合爆炸式复杂度。
- 对 DORA 指标动手脚： 拆分部署来刷高频率，而不是真正改善流动性。
- 没有反馈闭环： 结果从未被度量，导致交付永远无法反哺下一轮发现周期。
成熟度模型
- 第 1 级，启动： 发布是人工的、低频次的、高仪式感的；测试大多是人工的、手动运行的；成功的标准是”它发布出去了”；回滚很痛苦，也是临时想办法；对交付应该如何运作，没有共同的理解。
- 第 2 级，发展： 一些团队搭建了带自动化构建和少量测试的 CI；发布是按计划进行的；有了基础的监控；各团队之间的做法参差不齐，DORA 指标尚未被追踪，因此交付在局部有所改善，但在整个组织范围内并不一致。
- 第 3 级，标准化： 一条有文档记录的标准化流水线在全组织范围内被强制执行：持续交付配上自动化的测试和安全门禁、带回滚能力的渐进式部署，以及以策略即代码强制执行的职责分离。这条流水线提供一条不可篡改的审计轨迹，每个团队都遵循同一条受版本控制的路径，而不是各自定制的路径。
- 第 4 级，管理： 流水线本身被依据基线进行度量和控制。四项 DORA 指标（部署频率、前置时间、变更失败率、恢复时间）、SLO 达成率、错误预算消耗，以及诸如周期时间和在制品之类的流动指标，都会被对照目标进行追踪，门禁和回滚会依据度量出的阈值而触发，而不是依靠主观判断。开关债务、测试不稳定率和前置时间的退化都被监控，每一个通过或不通过的决定都建立在证据之上。
- 第 5 级，编排： 交付被持续改进，并与发现和风险规划整合在一起。持续部署在合适的地方运行，配合渐进式交付和自动化回滚；功能以被度量的实验形式上线，其结果指标回流到下一轮投入决策；顶尖水平的 DORA 表现通过这条标准化通路在各团队之间得以维持；组织会随着负载、风险和产品组合的变化，自适应地重新调整门禁、阈值和容量。
讨论思路
- 你们目前的四项 DORA 指标是什么，从提交到生产环境的流程中，最大的瓶颈在哪里？
- 你们今天能把部署和发布分开吗？如果不能，功能开关会为你们的风险状况带来什么改变？
- 你们的测试套件要跑多久，开发者对它的信任是否足以让他们不去绕开它？
- 上一次交付一个功能时，你们有没有度量它是否推动了它本该推动的那个指标？
- 在一个受监管的场景中，你们的变更控制流程是拖慢了交付速度，还是已经通过流水线被自动强制执行？
- 你们代码库里的哪些功能开关本应在几个月前就被移除？
关键要点
- 交付流水线把经过验证的想法，转化为正在运行、被度量的软件，并把结果反馈回发现流程（第 11.1 章）。
- 把整条路径自动化：快速的测试门禁、CI/CD，以及基础设施即代码，让流水线成为权威数据源。
- 把部署和发布分开，并配合自动回滚使用渐进式策略（功能开关、金丝雀、蓝绿部署）。
- 在三个层面进行度量：DORA／流动指标、可靠性／SLO，以及业务／用户结果。
- 速度和稳定性是互补关系，而不是取舍关系：能带来其中一个的实践，同样也能带来另一个。
- 流水线同样是一项合规控制：自动化产生一条不可篡改、持续更新的审计轨迹。
- 投资回报快、证据充分（DORA）、且不断复合增长；不投资的主要代价则是持续不断地被支付。
参考资料与延伸阅读
- Accelerate: The Science of Lean Software and DevOps，Nicole Forsgren、Jez Humble、Gene Kim 著（DORA 指标及其证据）。
- Continuous Delivery，Jez Humble 与 David Farley 著（奠基性著作）。
- The DevOps Handbook，Kim、Humble、Debois、Willis 著。
- The Phoenix Project，Gene Kim、Kevin Behr、George Spafford 著（关于流动的叙事作品）。
- Site Reliability Engineering，Beyer、Jones、Petoff、Murphy 编（SLI／SLO、错误预算）。
- Team Topologies，Matthew Skelton 与 Manuel Pais 著（标准化通路与交付团队设计）。
- Feature Flags / progressive delivery，Pete Hodgson 及 LaunchDarkly/Split 社区的相关著述。
- Google DORA，Accelerate State of DevOps 报告（年度报告）。
- Kim, Gene，The Unicorn Project（从开发者体验视角看流动）。
- Reinertsen, Donald，The Principles of Product Development Flow（批量大小、队列与流动经济学）。