软件交付的难题

一句话

你以为发布危险是因为「这次改动太大」，其实因果常常反过来——正因为发布得少，每次改动才那么大。《持续交付》第 1 章立下全书命题：交付之所以痛苦、高风险、耗时，根源在于发布过程手工、罕见、不可重复；解法是把构建、部署、测试、发布整个过程自动化成一条部署流水线（deployment pipeline），让每一次提交都成为候选发布版，把「上线」从一场需要熬夜与祈祷的事件，变成无聊到没人紧张的日常操作。

Glossary · 术语表

坐标

作者 Jez Humble 与 David Farley，成书时同在 ThoughtWorks。本章是全书 Part I「基础」的开篇，也是整本书的总纲：不讲任何具体工具，只把「交付为什么这么痛」摊开，再给出中心模式（部署流水线）与八条原则。下承第 2 章配置管理（把代码、配置、环境统统纳入版本控制，让系统可重现）、第 3 章持续集成，第 5 章把这里草描的流水线展开成全书骨架。今天的 Jenkins、GoCD、GitHub Actions、Argo CD，都是这条流水线的具体化身。

这章要解决什么

先还原 2010 年前后典型企业软件的样子：一年发布 2–4 次，窗口定在周五深夜或整个周末，一份几十页的部署手册，一屋子人待命，「回滚」意味着从数据库备份里恢复。痛在三处：反馈慢——周期时间以月计，缺陷在修复成本最高的时候才浮现；批量大——一次上线塞进成百个改动，出事时嫌疑范围大得没法查；不可重复——每次发布都是一场手艺表演，换个人、换台机器结果就不一样。

不解决会怎样？Knight Capital，2012 年 8 月 1 日。美国证券交易委员会（SEC）2013 年的行政处罚令记载：一次手工部署把新代码装上了 8 台生产服务器中的 7 台，漏掉一台；偏偏那台机器上，一个被复用的旧开关唤醒了多年未用的老算法，45 分钟内向市场发出数百万笔订单，公司损失超过 4.6 亿美元。一次「漏了一台机器」的手工部署——这就是本章要消灭的东西。

核心内容，讲透

一、三个发布反模式

反模式 1 · 手工部署软件。症状像张体检表：一份逐步描述「该敲什么命令」的长文档；靠人工测试确认「它到底起来了没有」；上线中频繁打电话问开发「这步为什么报错」；现场临时改配置；一次发布耗几个钟头而不是几分钟；结果不可预测，常常得回滚。作者的判据很锋利：换一批人、换一台机器就跑不出同样结果的，不是流程，是手艺。对策是把部署做成完全脚本化、所有环境跑同一套的自动过程。

反模式 2 · 只在开发完成后才部署到类生产环境。症状：开发期只在本机跑；测试人员拿不到像样的环境；运维临发布才第一次见到这个应用。于是装配、依赖、配置、数据迁移这些问题全被推迟到最没时间处理的那一刻。对策是从第一天起就往类生产环境部署，把「部署」反复演练。

反模式 3 · 手工管理生产环境的配置。症状：同一个包在预发装得好好的、一到生产就挂；集群里总有那么几台特别爱出问题；没办法把系统（操作系统、补丁、中间件、数据库、配置）退回到过去某个已知状态。对策：环境的每个方面都纳入版本控制、由脚本自动建立（第 11 章——「基础设施即代码」的雏形）。

二、目标与部署流水线：这本书的中心模式

作者把目标说得很直白：找到一种高效、快速、可靠地交付有价值软件的方式。落成可操作的指标就是周期时间——从「决定做一个改动」到「它在生产上跑起来」有多久。围绕它，本章给出全书的中心模式：部署流水线，即「应用的构建、部署、测试、发布过程的自动化实现」。

一次提交进入流水线后逐关推进：提交阶段（编译、单测、静态分析）→ 自动化验收测试 → 手工 / 用户验收 / 容量测试 → 发布。关键不在关卡本身，而在三件事：每一关都由同一套脚本、同一份制品驱动；任何一关失败，这个版本立刻出局；结果要在几分钟到几十分钟内回到提交者面前。书里给的经验值是提交阶段控制在十分钟以内（第 7 章展开）——超过这个数，人就不再等它、转头开新工作，反馈也就失去了意义。

三、反馈的三条要求

一条流水线值不值钱，全看反馈闭环。本章提了三条：① 每一次改动都必须触发反馈过程——不能挑着跑、不能「这次改得小就先不测」；② 反馈必须尽快到达——越快，「出错」到「发现」之间夹的改动越少，定位越便宜；③ 团队必须接收反馈并据此行动。第三条最常被忽视：主干红了两周没人修，CI 服务器就只是个装饰品。

四、发布候选版：每一次签入都是候选

传统做法是等测试都跑完，从若干构建里提名一个作为发布候选版，再走一遍完整回归。作者把它反了过来：每一次签入（check-in）都产生一个潜在的发布版本——每个构建默认都是候选，流水线的每一关都在证伪它，只有一路走到底没被淘汰的版本才有资格上生产。这个转变很关键：「什么时候能发」从一个由人拍板的里程碑，变成流水线随时回答的状态。

五、八条软件交付原则

本章末尾给出八条原则，是全书的价值观压缩包：

• ① 建立可重复、可靠的发布流程——发布之所以容易，是因为每一部分都已演练过几百次。
• ② 几乎一切都要自动化——注意是「几乎」。
• ③ 把一切纳入版本控制——代码、配置、脚本、数据库变更、环境定义，任何人都应能从版本库重建整套系统。
• ④ 如果一件事很痛，就更频繁地做它，并把痛提前——频率会逼出自动化。
• ⑤ 把质量内建（build quality in）——借戴明（W. Edwards Deming）的话：质量不是最后由测试「检」出来的，是在过程中造出来的。
• ⑥「完成」意味着「已发布」——停在「开发完了待测」的东西是库存，不是成果。
• ⑦ 交付过程人人有责——不是开发扔给测试、测试扔给运维。
• ⑧ 持续改进——把流水线本身当作需要不断打磨的产品。

收益条条对着前面的痛：赋能团队（一键自助部署）、减少错误（尤其是交接处的错误，配置不再靠口头传递）、降低压力、部署灵活，以及熟能生巧——同一套流程在每个环境都跑，真上生产时它已被执行过成百上千次。

关键权衡与选型

这一章真正的争论点不在「要不要自动化」，而在先自动化什么、哪里该停手、以及为此付出什么。

表 1 · 大爆炸式发布 vs 持续交付（代价也照实写）

表 2 · 三个常被混为一谈的「持续」

本书主张的是中间那一档。持续部署更激进，也不是人人适用——客户端软件、嵌入式设备、强监管系统里，「什么时候让用户拿到」本就是业务与合规决定，不该交给流水线。

至于「几乎一切都要自动化」里的那个「几乎」：该自动化的是编译打包、测试、环境搭建、部署、数据库迁移、制品晋级；该留给人的是探索性测试（靠好奇心撞未知问题）、可用性判断（好不好用无法断言成 true/false）、给客户演示，以及「现在要不要发给用户」这个决定。

为什么重要 / 落到真实系统

这一章之所以成为整个 DevOps 运动的地基，是因为它把「发布」这件长期被当成组织问题、甚至运气问题的事，重新定义成一个可以工程化的技术问题。今天的工具都是它的化身：Jenkins / GitHub Actions 是流水线的执行器；Docker 镜像、Terraform、Ansible 是「把环境纳入版本控制」的答案；Argo CD、Spinnaker 把部署做成可观测、可回滚的自动过程；特性开关（feature flag）让「Done means released」在不向用户暴露半成品的前提下成立。面试里那句「说说你们的发布流程」考的就是这一章——能不能报出周期时间、单次批量、回滚手段，以及哪一关拦住了什么。

易错点与争议

• 把持续交付等同于持续部署：本章主张的是「每个通过流水线的构建都具备上线资格」，按不按那个按钮是业务决策；自动直推生产是更激进的持续部署，并非所有产品都适用。
• 误读「自动化一切」：原则是 automate almost everything。探索性测试、可用性判断、发布审批天生该由人做，自动化掉反而丢掉价值。
• 以为买个 CI 服务器就叫持续交付：三个反模式里有两个（类生产环境、环境配置）根本不在 CI 服务器的射程内。后来的实证（DORA）也指向同一结论：主干开发、松耦合架构、团队授权这些非工具因素才是真瓶颈。
• 时代局限：2010 年成书，那时没有成熟的容器、Kubernetes、云上按需环境。书里花大力气讨论的「怎么把环境搭得一致」，今天大部分被容器镜像与基础设施即代码直接解决；反过来云原生也带来新问题——几十条流水线的协同、供应链安全、制品签名。
• 分支模型的争议：本书强烈倾向主干开发、批评长生命周期的特性分支，而今天主流是 Pull Request 流。两者未必冲突（短命分支 + 每天合回主干），但「长命分支 + 一台 CI 服务器」常被误当成持续集成。
• 「Done 意味着已发布」不等于每个需求都必须当天进生产：它说的是「没到用户手上的东西是库存」；用特性开关把部署与发布分开，才是可执行的落法。

要点