在DevOps领域，有一本书是绕不开的，那就是Jez Humble和David Farley合著的《持续交付：发布可靠软件的系统方法》（Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation）。

这本书出版于2010年，到现在已经十多年了。在这十多年里，软件开发和运维领域发生了翻天覆地的变化，DevOps从一个新兴概念变成了行业标配，容器、微服务、云原生、Kubernetes等新技术层出不穷。但重读《持续交付》这本书，我发现它的核心思想和原则不仅没有过时，反而更加深刻，更加重要。可以说，今天我们谈论的DevOps、CI/CD、自动化运维、可靠性工程等，其思想根源都能在这本书里找到。

这篇文章就来聊聊《持续交付》这本书，聊聊它的核心思想、主要内容、原则和实践，以及它对软件开发和运维的深远影响，为什么出版十多年后依然不过时，依然是DevOps领域的必读书。

这本书在讲什么

先简单介绍一下这本书。

《持续交付》的作者是Jez Humble和David Farley。Jez Humble是DevOps领域的先驱人物之一，曾在ThoughtWorks工作，后来创办了DevOps Research and Assessment（DORA）公司，研究DevOps对组织绩效的影响，提出了著名的DORA四项指标（部署频率、变更前置时间、变更失败率、恢复时间）。David Farley也是ThoughtWorks的资深技术专家，在持续交付和敏捷开发领域有很深的造诣。

这本书出版于2010年，那时候DevOps这个词刚刚被提出（2009年），持续集成已经比较普及，但持续交付还是一个比较新的概念。这本书系统地阐述了持续交付的思想、原则和实践，成为了持续交付领域的奠基之作，也成为了DevOps运动的重要思想来源。

书的内容非常丰富，大致可以分为几个部分：

第一部分是持续交付的问题和原则。介绍了软件交付面临的问题（发布周期长、风险高、质量差、效率低等），持续交付的核心思想和原则，以及配置管理、持续集成、自动化测试等基础实践。

第二部分是持续交付的实践。详细介绍了持续交付流水线的各个环节，包括构建流水线、自动化测试策略、部署流水线、环境管理、数据迁移、版本控制、发布策略等。每个环节都有详细的原则、方法和最佳实践，还有很多真实的案例。

第三部分是持续交付的推广和组织变革。介绍了如何在组织中推广持续交付，如何进行组织变革，如何管理依赖和风险，如何度量和改进等。这部分内容对于想要在组织中推行持续交付的管理者和技术负责人非常有价值。

总的来说，这本书既有理论高度，又有实践深度，既有思想原则，又有具体方法，是一本非常全面、非常实用的持续交付指南。

持续交付的核心思想

要理解这本书，首先要理解持续交付的核心思想。

持续交付（Continuous Delivery，简称CD）的定义是：一种软件工程方法论，通过自动化构建、测试和部署流程，使得软件能够以一种可靠、可持续的方式，随时发布到生产环境。

简单来说，持续交付的目标是让软件发布变成一件简单、可靠、低风险的事情，而不是一件复杂、危险、高风险的事情。

在传统的软件开发模式中，软件发布是一件很痛苦的事情。开发团队花了几个月时间开发新功能，然后在某个"发布日"集中发布。发布过程往往充满了风险和不确定性：代码合并冲突、测试不充分、环境不一致、部署脚本出错、回滚困难……发布日往往变成了"加班日"和"救火日"，发布之后还经常出现各种问题，需要紧急修复。

持续交付就是为了解决这些问题。它的核心思想可以概括为以下几点：

第一，频繁发布。持续交付主张小步快跑，频繁发布，而不是攒一大堆功能集中发布。每次发布只包含少量的变更，这样每次发布的风险就小，出了问题也容易定位和回滚。频繁发布还能让用户更快地用上新功能，更快地获得反馈，更快地迭代改进。

第二，自动化一切。持续交付强调自动化，构建、测试、部署、环境配置等所有环节都要自动化，尽量减少人工操作。人工操作容易出错，效率低，而且不可重复。自动化能提高效率，减少错误，保证一致性，让发布过程可靠、可重复。

第三，质量内建。持续交付强调质量不是测试出来的，而是构建出来的。质量应该内建到开发过程的每个环节，从需求分析、设计、编码、测试到部署，每个环节都要保证质量。自动化测试是质量内建的重要手段，单元测试、集成测试、端到端测试等多层次的自动化测试，能够在每次变更时快速发现问题，保证软件质量。

第四，持续反馈。持续交付强调快速反馈，从提交代码到构建、测试、部署，每个环节都要快速反馈结果。如果代码有问题，要在几分钟内发现，而不是等到发布前才发现。快速反馈能让开发者及时修复问题，减少问题积累，提高开发效率。

第五，随时可发布。持续交付的最终目标是让软件随时处于可发布的状态，任何时候都可以一键发布到生产环境。这意味着主干分支的代码始终是稳定的、可发布的，每次提交都经过了充分的自动化测试，部署流程是自动化的、可靠的。达到这个状态之后，发布就不再是一件需要专门准备的大事，而是一件随时可以做的小事。

这些核心思想，看起来简单，但真正做到并不容易。它需要开发流程、工具链、组织结构、文化等多方面的变革。但一旦做到了，软件交付的效率和质量都会有质的飞跃。

持续交付的原则

除了核心思想，这本书还提出了持续交付的几个重要原则，这些原则是指导持续交付实践的基础。

第一个原则：每次提交都应该产生一个可发布的版本。这是持续交付最基本的原则。这意味着主干分支的代码必须始终是稳定的、可发布的，每次提交都要经过充分的自动化测试，确保不会破坏现有功能。如果提交的代码有问题，要在几分钟内发现并修复。为了做到这一点，需要有快速的构建和测试流水线，需要有良好的测试覆盖，需要有代码审查等质量保障措施。

第二个原则：自动化重复的过程。持续交付强调自动化，凡是重复的过程都应该自动化。构建、测试、部署、环境配置、数据迁移等，都应该自动化。自动化不仅能提高效率，减少人为错误，还能保证过程的一致性和可重复性。自动化是持续交付的基础，没有自动化，就没有持续交付。

第三个原则：把一切纳入版本控制。源代码、配置文件、构建脚本、部署脚本、环境配置、数据库迁移脚本等，所有和软件交付相关的东西都应该纳入版本控制。版本控制是配置管理的基础，它能保证所有东西都是可追溯的、可回滚的，不同环境的配置是一致的。很多交付问题都是因为配置没有纳入版本控制，导致环境不一致、配置混乱引起的。

第四个原则：如果它疼，就把它做频繁，然后把疼的部分自动化。这是一个很有意思的原则。很多团队因为发布很疼（风险高、问题多、需要加班），所以尽量减少发布频率，结果每次发布的变更更多，风险更高，更疼，形成恶性循环。持续交付的做法恰恰相反：既然发布疼，那就更频繁地发布，每次发布少量变更，降低风险；然后把发布过程中疼的部分（容易出错、效率低的环节）自动化，让发布变得不疼。这样就形成了良性循环：发布越频繁，风险越低；发布越自动化，越可靠。

第五个原则：交付完成的定义包括"已发布到生产环境"。在传统的开发模式中，开发完成的定义往往是"代码写完了"或者"测试通过了"，但实际上，只有发布到生产环境，用户真正用上了，软件才算真正交付了。持续交付强调，交付完成的定义应该是"已发布到生产环境并且运行正常"。这就要求开发团队对软件的整个生命周期负责，从开发到测试到部署到运维，而不是写完代码就扔给测试和运维。这也是DevOps"开发运维一体化"思想的体现。

第六个原则：持续改进。持续交付不是一次性的项目，而是一个持续改进的过程。没有完美的交付流程，只有不断优化的交付流程。团队应该定期回顾交付过程中的问题，度量交付绩效（比如部署频率、前置时间、变更失败率、恢复时间等），找到瓶颈和改进点，持续优化。持续改进是持续交付能够持续有效、不断提升的保证。

这些原则是持续交付的灵魂，它们指导着持续交付的实践，也体现了持续交付的思想精髓。理解了这些原则，才能真正理解持续交付，而不是只学了一些工具和流程的皮毛。

持续交付的关键实践

有了思想和原则，还需要具体的实践来落地。这本书详细介绍了持续交付的各种实践，这里挑几个最关键的聊聊。

第一个关键实践：持续集成（Continuous Integration，简称CI）。持续集成是持续交付的基础，它的核心思想是开发者频繁地（每天至少一次）把代码合并到主干分支，每次合并都触发自动化的构建和测试，确保代码不会破坏现有功能。持续集成能尽早发现集成问题，减少代码合并冲突，保证主干分支的稳定性。要做好持续集成，需要有快速的构建流水线、良好的自动化测试覆盖、代码审查机制等。持续集成是持续交付的第一步，没有持续集成，就没有持续交付。

第二个关键实践：自动化测试策略。自动化测试是持续交付的质量保障，是信心的来源。没有充分的自动化测试，就不敢频繁发布，因为每次发布都可能引入bug。持续交付强调多层次的自动化测试策略，也就是著名的"测试金字塔"：底层是大量的单元测试，运行快、成本低、覆盖细；中间层是适量的集成测试，验证模块之间的交互；顶层是少量的端到端测试，验证整个系统的关键流程。这样的测试策略，既能保证测试覆盖，又能保证测试速度和维护成本。除了测试金字塔，还有契约测试、验收测试、性能测试、安全测试等，根据项目需要选择。

第三个关键实践：部署流水线（Deployment Pipeline）。部署流水线是持续交付的核心工具，它把软件从提交代码到发布到生产环境的整个过程自动化、流水线化。一次代码提交触发流水线，依次经过构建、单元测试、集成测试、代码质量检查、打包、部署到测试环境、端到端测试、部署到预发布环境、验收测试、部署到生产环境等环节。每个环节自动化执行，任何一个环节失败就停止流水线，通知开发者修复。部署流水线让交付过程可视化、自动化、可追溯，大大提高了交付效率和可靠性。

第四个关键实践：基础设施即代码（Infrastructure as Code，简称IaC）。环境不一致是很多交付问题的根源：开发环境能跑，测试环境跑不了；测试环境没问题，生产环境出问题。基础设施即代码就是用代码来定义和管理基础设施（服务器、网络、配置等），通过版本控制来管理基础设施的变更，通过自动化工具来 provision 和配置环境。这样就能保证不同环境的一致性，环境变更可追溯、可回滚，环境搭建自动化、可重复。常见的IaC工具有Terraform、Ansible、Puppet、Chef等，容器技术（Docker、Kubernetes）也让基础设施即代码变得更加普及和方便。

第五个关键实践：蓝绿部署和金丝雀发布。这是两种低风险的发布策略。蓝绿部署是同时维护两套环境（蓝和绿），一套运行当前版本，一套部署新版本，测试通过后，把流量切换到新版本环境，如果出问题，立刻切回旧版本。金丝雀发布是先把新版本部署到一小部分服务器，让一小部分用户使用新版本，观察一段时间没问题，再逐步扩大范围，直到全量发布。这两种发布策略都能大大降低发布风险，出了问题影响范围小，回滚快。在持续交付中，低风险的发布策略是频繁发布的重要保障。

第六个关键实践：数据库迁移自动化。数据库变更往往是发布中最棘手的部分，因为数据库有状态，不能像无状态服务那样随意回滚。持续交付强调数据库迁移脚本化、自动化，把数据库迁移脚本纳入版本控制，和应用代码一起管理，每次发布自动执行迁移脚本。还要设计兼容的数据库变更，比如先加字段（允许为空），再部署应用使用新字段，最后再把字段改为非空，这样可以保证应用和数据库的兼容性，支持零停机发布和回滚。数据库迁移自动化是持续交付中一个很重要但经常被忽视的实践。

这些关键实践是持续交付落地的具体方法，它们相互配合，共同构成了持续交付的实践体系。掌握了这些实践，就能在实际项目中落地持续交付。

为什么它能成为经典

《持续交付》为什么能成为DevOps领域的经典之作？我觉得有几个原因。

第一，它提出了系统性的方法论。在《持续交付》之前，虽然已经有持续集成、敏捷开发等实践，但还没有一本书系统地阐述软件交付的完整方法论。《持续交付》第一次把软件交付的整个过程（从提交代码到发布生产）作为一个系统来研究，提出了完整的思想、原则、实践和工具，形成了一套系统性的方法论。这套方法论不是零散的经验总结，而是有理论基础、有逻辑体系、有实践指导的完整框架。这种系统性，让它成为了这个领域的奠基之作。

第二，它的思想具有前瞻性。这本书出版于2010年，但它提出的很多思想和原则，在今天看来依然非常前沿，甚至很多团队今天还没有做到。比如"每次提交都产生可发布版本""自动化一切""基础设施即代码""交付完成的定义是已发布到生产环境""开发运维一体化"等，这些思想在今天依然是DevOps和云原生时代的核心理念。一本书出版十多年后依然不过时，甚至依然超前，这就是经典的标志。

第三，它的实践具有可操作性。这本书不是一本空谈理论的书，而是一本非常实用的实践指南。它不仅讲了"为什么"，更讲了"怎么做"。每个实践都有详细的方法、步骤、工具、案例，读者可以照着做。书里有很多真实的案例，来自作者在ThoughtWorks的咨询经历，这些案例让抽象的原则变得具体可感。这种实用性，让这本书不仅有理论价值，还有实践指导价值，读者读完之后就能在实际项目中应用。

第四，它深刻影响了DevOps运动。《持续交付》是DevOps运动的重要思想来源之一。DevOps强调开发和运维的协作、自动化、持续交付、快速反馈等，这些思想在《持续交付》里都有系统的阐述。很多DevOps的实践和工具，比如CI/CD流水线、基础设施即代码、自动化测试、蓝绿部署等，都能在这本书里找到思想根源。DORA的DevOps研究（Jez Humble是DORA的联合创始人），也深受这本书的影响。可以说，没有《持续交付》，就没有今天的DevOps。这本书的影响力，已经超越了一本书的范畴，成为了一场技术运动的思想基础。

第五，它关注的是永恒的问题。软件交付的效率、质量、风险，这些是软件开发中永恒的问题，不会因为技术的变化而消失。不管是瀑布时代还是敏捷时代，不管是单体应用还是微服务，不管是物理服务器还是云原生，软件怎么高效、高质量、低风险地交付，都是每个团队都要面对的问题。《持续交付》关注的就是这些永恒的问题，它提出的思想和原则，不依赖于特定的技术，具有普遍的适用性。技术会变，工具会变，但这些核心思想和原则不会变，这就是它能成为经典的根本原因。

因为这些原因，《持续交付》成为了DevOps领域的经典之作，成为了每个软件工程师、运维工程师、技术管理者都应该读的书。

重读这本书的新感受

最近重读《持续交付》，我有一些新的感受和体会。

第一个感受是：很多团队今天还没有做到持续交付。这本书出版十多年了，持续交付和DevOps的概念已经普及了，很多团队都说自己在做DevOps，有CI/CD流水线，用Docker和Kubernetes。但实际上，很多团队只是做到了"持续集成"，还没有真正做到"持续交付"。很多团队的发布还是需要专门的发布日，还是需要手工操作，还是有很高的发布风险，发布之后还是经常出问题。很多团队的CI/CD流水线只是"构建+部署到测试环境"，生产环境的发布还是手工的，或者只是半自动化。很多团队的自动化测试覆盖不足，单元测试少，集成测试不稳定，端到端测试几乎没有，导致不敢频繁发布。这说明，持续交付的思想虽然普及了，但真正落地还需要时间，还需要更多的努力。这本书在今天依然有很强的现实意义。

第二个感受是：云原生技术让持续交付更容易实现了。这本书出版的时候，容器技术还没有出现（Docker是2013年才出现的），Kubernetes更是还没有影子。那时候做持续交付，环境管理、部署自动化、弹性伸缩等都很麻烦，需要自己写很多脚本，用很多工具。今天，有了Docker、Kubernetes、Helm、Terraform等云原生技术，环境管理、部署自动化、弹性伸缩等都变得简单了很多。容器镜像让"一次构建，到处运行"成为现实，Kubernetes让部署和伸缩自动化，基础设施即代码工具让环境管理自动化。这些技术大大降低了持续交付的落地门槛，让更多的团队能够实现持续交付。可以说，云原生技术是持续交付思想的最佳载体，让这本书里的很多理想变成了现实。

第三个感受是：持续交付的核心还是人和文化，不是工具。虽然今天的工具比十多年前强大了很多，但持续交付的落地依然不容易，最大的障碍往往不是工具，而是人和文化。很多团队买了最好的CI/CD工具，用了最先进的云原生技术，但交付效率和质量依然没有提升，因为团队的文化没有变：开发还是写完代码就扔给测试，运维还是和开发对立，测试还是在开发完成之后才开始，发布还是集中式的大爆炸式发布，出了问题还是互相甩锅。持续交付不仅仅是工具和流程的变革，更是组织文化的变革，需要开发、测试、运维的协作，需要"你构建，你运行"的文化，需要持续改进的文化。没有文化的变革，再好的工具也没用。这一点，这本书里也有强调，但在今天看来更加深刻。

第四个感受是：DORA指标让持续交付的效果可度量。这本书出版的时候，还没有DORA指标。后来Jez Humble创办了DORA，提出了四项度量指标：部署频率、变更前置时间、变更失败率、恢复时间。这四项指标，让持续交付的效果可以量化度量，让团队能够看到自己的交付绩效，找到改进的方向。今天，DORA指标已经成为了DevOps绩效度量的行业标准，很多团队都在用这四项指标来度量和改进自己的交付能力。这可以说是《持续交付》思想的延伸和发展，让持续交付从"凭感觉"变成了"数据驱动"。

这些新的感受，让我对《持续交付》有了更深的理解，也更加认识到这本书的价值和影响力。

给想读这本书的朋友的建议

最后给想读这本书的朋友一些建议。

第一，不要被厚度吓到。这本书挺厚的，有五百多页，内容很多。不要想着一口气读完，可以分章节慢慢读，重点读和自己当前工作相关的部分。比如如果你是开发，可以重点读持续集成、自动化测试、配置管理等部分；如果你是运维，可以重点读部署流水线、环境管理、发布策略等部分；如果你是技术管理者，可以重点读原则、组织变革、度量改进等部分。

第二，不要只读书，要实践。持续交付是一门实践的学问，光读书是不够的，一定要在实际项目中实践。可以从一个小项目开始，尝试落地持续交付的一些实践，比如先搭建CI流水线，写单元测试，实现自动化部署，然后逐步完善。在实践中遇到问题，再回到书里找答案，这样理解会更深刻。

第三，不要照搬，要根据实际情况调整。书里的实践是通用的最佳实践，但每个团队的情况不一样，技术栈、团队规模、业务特点、组织文化都不一样，不要照搬书里的做法，要根据自己的实际情况调整。比如小团队和大团队的做法不一样，初创公司和大型企业的做法不一样，互联网产品和企业级软件的做法不一样。理解了核心思想和原则，然后根据实际情况选择合适的实践，才是正确的做法。

第四，关注思想和原则，不要只学工具和流程。很多人学持续交付，只学了一些工具和流程，比如用了Jenkins、Docker、Kubernetes，搭了流水线，就以为自己在做持续交付了。但实际上，工具和流程只是表面，思想和原则才是核心。如果没有理解"每次提交可发布""自动化一切""质量内建""持续改进"等核心思想，工具用得再好也不是真正的持续交付。读书的时候要重点理解思想和原则，工具和流程可以根据实际情况选择。

第五，结合最新的技术和实践来读。这本书出版于2010年，有些工具和实践已经有了新的发展。比如容器、Kubernetes、云原生、GitOps、平台工程等，这些在书里没有详细介绍，但它们是持续交付思想在新时代的发展。读书的时候，可以结合最新的技术和实践来思考，看看书里的思想在新技术下如何应用，这样会有更多的收获。

第六，组织团队一起读。持续交付不是一个人的事情，需要整个团队的理解和参与。可以组织团队一起读这本书，分章节讨论，结合团队的实际情况讨论如何落地。团队一起读，一起讨论，一起实践，效果会比一个人读好很多，也更容易推动组织变革。

这些建议希望能帮到想读这本书的朋友，让大家能从这本书中获得更多的收获。

写在最后

《持续交付》，DevOps领域的必读书。

它系统地阐述了持续交付的思想、原则和实践，提出了一套完整的软件交付方法论，深刻影响了DevOps运动和整个软件行业。出版十多年后，它的核心思想和原则依然不过时，依然是每个软件工程师、运维工程师、技术管理者都应该学习和实践的。

在今天这个云原生、AI辅助开发的时代，软件交付的效率和质量比以往任何时候都更加重要。技术在变，工具在变，但高效、高质量、低风险地交付软件，这个核心需求不会变。《持续交付》这本书，正是指导我们实现这个目标的经典之作。

如果你还没有读过这本书，我强烈推荐你读一读。它可能不会让你立刻成为技术大牛，但它会改变你对软件交付的理解，提升你对软件交付的认知，让你在职业生涯中受益无穷。

如果你已经读过了，也推荐你再读一遍。经典的书，每读一遍都会有新的收获。特别是在有了更多的实践经验之后再读，会有更深的理解和更多的体会。

最后用书中的一句话来结尾："我们的目标不是更快地发布软件，而是更可靠地发布软件。"

愿我们都能实现可靠、高效、持续的软件交付，让发布不再是一件痛苦的事情，而是一件日常的、愉快的事情。