（已有24条评价）基本信息
- 原书名：Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation
- 原出版社： Addison-Wesley Professional
- 作者： (英)Jez Humble David Farley
- 译者： 乔梁
- 丛书名： 图灵程序设计丛书
- 出版社：人民邮电出版社
- ISBN：9787115264596
- 上架时间：2011-10-17
- 出版日期：2011 年10月
- 开本：16开
- 页码：362
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 综合
【插图】
编辑推荐
第21届Jolt大奖获奖作品
马丁·福勒作序推荐
原著被誉为2010年最重要的技术书
软件开发的新经典
内容简介
目录
《持续交付--发布可靠软件的系统方法》
第一部分 基础篇
第1章 软件交付的问题 2
1.1 引言 2
1.2 一些常见的发布反模式 3
1.2.1 反模式：手工部署软件 4
1.2.2 反模式：开发完成之后才向类生产环境部署 5
1.2.3 反模式：生产环境的手工配置管理 7
1.2.4 我们能做得更好吗 8
1.3 如何实现目标 9
1.3.1 每次修改都应该触发反馈流程 10
1.3.2 必须尽快接收反馈 11
1.3.3 交付团队必须接收反馈并作出反应 12
1.3.4 这个流程可以推广吗 12
1.4 收效 12
1.4.1 授权团队 13
1.4.2 减少错误 13
1.4.3 缓解压力 15
1.4.4 部署的灵活性 16
1.4.5 多加练习，使其完美 17
第一部分 基础篇
第1章 软件交付的问题 2
1.1 引言 2
1.2 一些常见的发布反模式 3
1.2.1 反模式：手工部署软件 4
1.2.2 反模式：开发完成之后才向类生产环境部署 5
1.2.3 反模式：生产环境的手工配置管理 7
1.2.4 我们能做得更好吗 8
1.3 如何实现目标 9
1.3.1 每次修改都应该触发反馈流程 10
1.3.2 必须尽快接收反馈 11
1.3.3 交付团队必须接收反馈并作出反应 12
1.3.4 这个流程可以推广吗 12
1.4 收效 12
1.4.1 授权团队 13
1.4.2 减少错误 13
1.4.3 缓解压力 15
1.4.4 部署的灵活性 16
1.4.5 多加练习，使其完美 17
译者序
译者序
十年前，敏捷软件开发方法在国内还少有人知，现在却已渐成主流。持续集成作为一个敏捷开发最佳实践，近年来也被广泛接受。然而，它们并没有很好地解决所谓的“最后一公里问题”，即如何让软件从“开发完成”迅速实现“上线发布”。
本书的问世让这个问题有了答案。通过将敏捷和持续集成的理念应用到整个软件生命周期中，利用各种敏捷原则与最佳实践打破了用户、交付团队及运维团队之间的壁垒，让原本令人紧张、疲惫的软件发布过程变得轻松了，令原本枯燥易错的部署操作已变得只需轻点鼠标即可完成。
本书首次从业务视角阐述了持续交付的必要性，并从现实问题出发，对软件交付过程进行了彻底的剖析，指出了各交付环节所需遵守的原则与最佳实践，列举了各种常见的反模式。书中的案例详实，贴近生产一线，读过之后，你一定会产生强烈的共鸣。
本书为所有人带来了曙光：
作为IT部门的主管，当你发现这本书后，一定会觉得眼前豁然开朗；
作为项目经理，当你读完本书的前五章后，一定会觉得手中的项目不再令你望而却步；
作为开发人员，当你在多个分支之间痛苦地解决着合并冲突时，本书中的配置管理实践一定会让你觉得看到了希望；
作为测试人员，当你在各类测试间疲于奔命时，本书中的自动化测试章节一定会令你觉得神清气爽；
作为运维人员，当你在为各类环境的维护而苦恼不休时，本书中的环境管理内容一定会让你觉得心旷神怡。
持续交付以全面的版本控制和全面自动化为核心，通过各角色的紧密合作，力图让每个发布都变成可靠且可重复的过程。
作为Cruise 的业务分析师，我暗自庆幸能和Cruise团队的其他成员一起见证这本书的问世，并在Cruise整个研发过程里采用书中的诸多实践，为本书提供了素材。
正因了解本书对软件行业的重大意义，在其出版之前，我就向作者之一Jez Humble提出，希望将这本书引入中国。也正因如此，在此书英文版出版后的短短一年内，中文版就能与国内读者见面。同时，也感谢图灵教育以专业的态度，制订了完善的出版计划，本书才得以尽早出版。
此外，谨以此书献给我的妻子兆霞和儿子皓天。他们的支持和鼓励让我在过去的十个月中，利用业余时间顺利地完成了这数百页的翻译工作。
昨日获悉，本书获得了2011年Jolt图书大奖，这足以证明它值得一读。希望读完之后，你也和我一样有所收获，并把它介绍给更多还在痛苦中艰难前行的软件从业者。
乔梁
于2011年8月
十年前，敏捷软件开发方法在国内还少有人知，现在却已渐成主流。持续集成作为一个敏捷开发最佳实践，近年来也被广泛接受。然而，它们并没有很好地解决所谓的“最后一公里问题”，即如何让软件从“开发完成”迅速实现“上线发布”。
本书的问世让这个问题有了答案。通过将敏捷和持续集成的理念应用到整个软件生命周期中，利用各种敏捷原则与最佳实践打破了用户、交付团队及运维团队之间的壁垒，让原本令人紧张、疲惫的软件发布过程变得轻松了，令原本枯燥易错的部署操作已变得只需轻点鼠标即可完成。
本书首次从业务视角阐述了持续交付的必要性，并从现实问题出发，对软件交付过程进行了彻底的剖析，指出了各交付环节所需遵守的原则与最佳实践，列举了各种常见的反模式。书中的案例详实，贴近生产一线，读过之后，你一定会产生强烈的共鸣。
本书为所有人带来了曙光：
作为IT部门的主管，当你发现这本书后，一定会觉得眼前豁然开朗；
作为项目经理，当你读完本书的前五章后，一定会觉得手中的项目不再令你望而却步；
作为开发人员，当你在多个分支之间痛苦地解决着合并冲突时，本书中的配置管理实践一定会让你觉得看到了希望；
作为测试人员，当你在各类测试间疲于奔命时，本书中的自动化测试章节一定会令你觉得神清气爽；
作为运维人员，当你在为各类环境的维护而苦恼不休时，本书中的环境管理内容一定会让你觉得心旷神怡。
持续交付以全面的版本控制和全面自动化为核心，通过各角色的紧密合作，力图让每个发布都变成可靠且可重复的过程。
作为Cruise 的业务分析师，我暗自庆幸能和Cruise团队的其他成员一起见证这本书的问世，并在Cruise整个研发过程里采用书中的诸多实践，为本书提供了素材。
正因了解本书对软件行业的重大意义，在其出版之前，我就向作者之一Jez Humble提出，希望将这本书引入中国。也正因如此，在此书英文版出版后的短短一年内，中文版就能与国内读者见面。同时，也感谢图灵教育以专业的态度，制订了完善的出版计划，本书才得以尽早出版。
此外，谨以此书献给我的妻子兆霞和儿子皓天。他们的支持和鼓励让我在过去的十个月中，利用业余时间顺利地完成了这数百页的翻译工作。
昨日获悉，本书获得了2011年Jolt图书大奖，这足以证明它值得一读。希望读完之后，你也和我一样有所收获，并把它介绍给更多还在痛苦中艰难前行的软件从业者。
乔梁
于2011年8月
前言
引言
昨天，老板让你给客户演示一下产品很好的新特性，但你却什么都演示不了。所有新功能都只开发了一半，没人能让这个系统运行起来。你能拿到代码，可以编译，所有的单元测试在持续集成服务器上都能跑过，但是还要花几天才能把这个新版本发布到对外公开的UAT环境中。这种临时安排的商务演示活动算不上不合理吧？
在生产环境中发现了一个严重缺陷，它每天都在让你的公司蒙受损失。你也知道怎么修复它：只要在这个三层架构的系统中，修改那个被这三层都用到的库上的一行代码，然后再修改一下数据库中对应的表即可。但是，上次发布新版本到生产环境时，你花掉了整个周末的时间，而且直到凌晨三点才完活儿。另外，上次执行部署的那个家伙在不久之后因厌倦这样的工作辞职了。你清楚地知道，下次发布肯定不是一个周末就能搞定的。也就是说，该系统在工作日也会停机一段时间。唉，要是业务人员也能理解我们的问题就好了。
虽然这些事都很常见，但这些问题并不是软件开发过程不可避免的产物，它们只是在暗示我们：某个地方做错了。软件发布应该是一个快速且可重复的过程。现在，很多公司都会在一天内发布很多次。甚至对于那些代码非常复杂的代码库来说，这样做也是可能的。我们在本书中就会告诉你如何做到这一点。
Poppendieck夫妇（Mary和Tom）问道：“在你的公司里，仅涉及一行代码的改动需要花多长时间才能部署上线？你的处理方式是否可重复且可靠呢？” 从“决定做某种修改”到“该修改结果正式上线”的这段时间称为周期时间（cycle time）。对任何项目而言，它都是一个极为重要的度量标准。
在很多组织中，周期时间的度量单位是周或者月，而且发布过程也是不可重复或不可靠的。部署常常是手工操作过程，甚至将软件部署到测试环境或试运行环境都需要一个团队来完成，更不用说部署到生产环境了。我们遇到过同样复杂的项目，它们曾经也是这种状态，但是经过深入的业务流程重组后，对于某一关键的修改，团队做到了小时级别甚至分钟级别的发布。之所以能做到，就是因为我们创建了一个完全自动化、可重复且可靠的过程，让变更顺利地经过构建、部署、测试和发布过程。在这里，自动化是关键，它让开发人员、测试人员和运营人员能够通过一键式操作完成软件创建和部署过程中的所有常见任务。
本书将讲述如何缩短从想法到商业价值实现的时间，并使之更安全，从而彻底改变软件交付方式。
软件交到用户手上之后才会为个人或公司带来收入。这是显而易见的事，但在大多数组织中，将软件发布到生产环境的过程是一种手工密集型的、易出错且高风险的过程。虽然几个月的周期时间很常见，但很多公司的情况会更糟糕：发布周期会超过一年。对于大公司，从一个想法到用代码实现它的时间每延迟一周就意味着多出数百万美元的机会成本，而且这些大公司每次发布所经历的时间往往也是最长的。
尽管如此，现代大多数的软件开发项目仍旧没有把低风险软件交付的机制和过程作为其组成部分。
我们的目标是改变软件交付方式，将其由开发人员的手工操作变成一种可靠、可预期、可视化的过程并在很大程度上实现了自动化的流程，而且它要具备易于理解与风险可量化的特点。使用本书所描述的方法，就有可能在几分钟或几个小时内把一个想法变成可交付到生产环境中的工作代码，而且同时还能提高交付软件的质量。
交付成功软件的成本绝大部分都是在首次发布后产生的。这些成本包括技术支持、维护、增加新功能和修复缺陷的成本。通过迭代方式交付的软件更是如此，因为首次发布只会包含能给用户提供价值的最小功能集合。因此本书的书名《持续交付》就来源于敏捷宣言的第一原则：“我们的首要任务是尽早持续交付有价值的软件并让客户满意。”[bibNp0]这也反映了这样一个现实：对于成功的软件，首次发布只是交付过程的开始。
书中描述的所有技术都与交付软件新版本给客户相关，旨在减少时间和降低风险。这些技术的核心是增加反馈，改进负责交付的开发、测试和运维人员之间的协作。这些技术能确保当需要修改应用程序（也许是修复缺陷，也许是开发新功能）时，从修改代码到正式部署上线之间的时间尽可能短，尽早发现缺陷以便快速修复，并更好地了解与本次修改相关的风险。
读者对象及本书内容
本书的一个主要目标是改善负责软件交付的相关人员之间的协作，尤其是开发人员、测试人员、系统和数据库管理员以及经理。
本书内容广泛，包括经常提到的配置管理、源代码控制、发布计划、审计、符合性和集成，以及构建、测试和部署流程的自动化。我们也会讲述自动化验收测试、依赖管理、数据库迁移，以及测试和生产环境的创建与管理等技术。
参与过软件开发的很多人认为与写代码相比，这些活动不那么重要。然而，根据我们的经验，它们会消耗大量的时间和精力，而且是成功交付软件的关键因素。当与这些活动相关的风险管理没有做到位时，它们就可能耗费很多资金，甚至经常会超过构建软件本身的成本。本书会告诉你如何了解这些风险，而且更重要的是，会教会你如何降低这些风险。
这个目标很大，我们当然无法在一本书中面面俱到。事实上，我们很有可能会疏远各类目标受众，比如由于没有深入讨论架构、行为驱动的开发和重构等问题而疏远开发人员，或由于没花足够多的篇幅讨论探索性测试和测试管理策略而疏远测试人员，或由于没有特别关注容量计划、数据库迁移和生产环境监控等问题而疏远运维人员。
然而，市面上已经有一些分别详细讨论这些内容的书了。我们认为，真正缺少的是一本讨论如何把各方面（包括配置管理、自动化测试、持续集成和部署、数据管理、环境管理以及发布管理）融合在一起的书。精益软件开发运动告诉我们很多事情，其中有一件就是“整体优化是非常重要的”。为了做到整体优化，用一种整体方法将交付过程中各个方面以及参与该过程的所有人联系在一起是非常必要的。只有当能够控制每一次从引入变更到发布的整个过程时，你才能开始优化和改进软件交付的速度和质量。
我们的目标是提供一个整体方案，并给出这个方案涉及的各种原则。我们会告诉你如何在自己的项目中使用这些实践。我们认为不会有一种一刀切的解决方案可以应对软件开发中的各个方面，更不用说像配置管理和企业系统的运维控制这么大的主题了。然而本书所述的基本内容是可以广泛应用于各种软件项目的，包括大的、小的、高技术要求或短平快的快速收益项目。
在开始实际应用这些原则时你会发现，针对特定场景还需要关于这些方面的更详细信息。本书最后列有一份参考书目，以及一些在线资源链接，你可以在其中找到关于本书中各主题的更详细信息。
昨天，老板让你给客户演示一下产品很好的新特性，但你却什么都演示不了。所有新功能都只开发了一半，没人能让这个系统运行起来。你能拿到代码，可以编译，所有的单元测试在持续集成服务器上都能跑过，但是还要花几天才能把这个新版本发布到对外公开的UAT环境中。这种临时安排的商务演示活动算不上不合理吧？
在生产环境中发现了一个严重缺陷，它每天都在让你的公司蒙受损失。你也知道怎么修复它：只要在这个三层架构的系统中，修改那个被这三层都用到的库上的一行代码，然后再修改一下数据库中对应的表即可。但是，上次发布新版本到生产环境时，你花掉了整个周末的时间，而且直到凌晨三点才完活儿。另外，上次执行部署的那个家伙在不久之后因厌倦这样的工作辞职了。你清楚地知道，下次发布肯定不是一个周末就能搞定的。也就是说，该系统在工作日也会停机一段时间。唉，要是业务人员也能理解我们的问题就好了。
虽然这些事都很常见，但这些问题并不是软件开发过程不可避免的产物，它们只是在暗示我们：某个地方做错了。软件发布应该是一个快速且可重复的过程。现在，很多公司都会在一天内发布很多次。甚至对于那些代码非常复杂的代码库来说，这样做也是可能的。我们在本书中就会告诉你如何做到这一点。
Poppendieck夫妇（Mary和Tom）问道：“在你的公司里，仅涉及一行代码的改动需要花多长时间才能部署上线？你的处理方式是否可重复且可靠呢？” 从“决定做某种修改”到“该修改结果正式上线”的这段时间称为周期时间（cycle time）。对任何项目而言，它都是一个极为重要的度量标准。
在很多组织中，周期时间的度量单位是周或者月，而且发布过程也是不可重复或不可靠的。部署常常是手工操作过程，甚至将软件部署到测试环境或试运行环境都需要一个团队来完成，更不用说部署到生产环境了。我们遇到过同样复杂的项目，它们曾经也是这种状态，但是经过深入的业务流程重组后，对于某一关键的修改，团队做到了小时级别甚至分钟级别的发布。之所以能做到，就是因为我们创建了一个完全自动化、可重复且可靠的过程，让变更顺利地经过构建、部署、测试和发布过程。在这里，自动化是关键，它让开发人员、测试人员和运营人员能够通过一键式操作完成软件创建和部署过程中的所有常见任务。
本书将讲述如何缩短从想法到商业价值实现的时间，并使之更安全，从而彻底改变软件交付方式。
软件交到用户手上之后才会为个人或公司带来收入。这是显而易见的事，但在大多数组织中，将软件发布到生产环境的过程是一种手工密集型的、易出错且高风险的过程。虽然几个月的周期时间很常见，但很多公司的情况会更糟糕：发布周期会超过一年。对于大公司，从一个想法到用代码实现它的时间每延迟一周就意味着多出数百万美元的机会成本，而且这些大公司每次发布所经历的时间往往也是最长的。
尽管如此，现代大多数的软件开发项目仍旧没有把低风险软件交付的机制和过程作为其组成部分。
我们的目标是改变软件交付方式，将其由开发人员的手工操作变成一种可靠、可预期、可视化的过程并在很大程度上实现了自动化的流程，而且它要具备易于理解与风险可量化的特点。使用本书所描述的方法，就有可能在几分钟或几个小时内把一个想法变成可交付到生产环境中的工作代码，而且同时还能提高交付软件的质量。
交付成功软件的成本绝大部分都是在首次发布后产生的。这些成本包括技术支持、维护、增加新功能和修复缺陷的成本。通过迭代方式交付的软件更是如此，因为首次发布只会包含能给用户提供价值的最小功能集合。因此本书的书名《持续交付》就来源于敏捷宣言的第一原则：“我们的首要任务是尽早持续交付有价值的软件并让客户满意。”[bibNp0]这也反映了这样一个现实：对于成功的软件，首次发布只是交付过程的开始。
书中描述的所有技术都与交付软件新版本给客户相关，旨在减少时间和降低风险。这些技术的核心是增加反馈，改进负责交付的开发、测试和运维人员之间的协作。这些技术能确保当需要修改应用程序（也许是修复缺陷，也许是开发新功能）时，从修改代码到正式部署上线之间的时间尽可能短，尽早发现缺陷以便快速修复，并更好地了解与本次修改相关的风险。
读者对象及本书内容
本书的一个主要目标是改善负责软件交付的相关人员之间的协作，尤其是开发人员、测试人员、系统和数据库管理员以及经理。
本书内容广泛，包括经常提到的配置管理、源代码控制、发布计划、审计、符合性和集成，以及构建、测试和部署流程的自动化。我们也会讲述自动化验收测试、依赖管理、数据库迁移，以及测试和生产环境的创建与管理等技术。
参与过软件开发的很多人认为与写代码相比，这些活动不那么重要。然而，根据我们的经验，它们会消耗大量的时间和精力，而且是成功交付软件的关键因素。当与这些活动相关的风险管理没有做到位时，它们就可能耗费很多资金，甚至经常会超过构建软件本身的成本。本书会告诉你如何了解这些风险，而且更重要的是，会教会你如何降低这些风险。
这个目标很大，我们当然无法在一本书中面面俱到。事实上，我们很有可能会疏远各类目标受众，比如由于没有深入讨论架构、行为驱动的开发和重构等问题而疏远开发人员，或由于没花足够多的篇幅讨论探索性测试和测试管理策略而疏远测试人员，或由于没有特别关注容量计划、数据库迁移和生产环境监控等问题而疏远运维人员。
然而，市面上已经有一些分别详细讨论这些内容的书了。我们认为，真正缺少的是一本讨论如何把各方面（包括配置管理、自动化测试、持续集成和部署、数据管理、环境管理以及发布管理）融合在一起的书。精益软件开发运动告诉我们很多事情，其中有一件就是“整体优化是非常重要的”。为了做到整体优化，用一种整体方法将交付过程中各个方面以及参与该过程的所有人联系在一起是非常必要的。只有当能够控制每一次从引入变更到发布的整个过程时，你才能开始优化和改进软件交付的速度和质量。
我们的目标是提供一个整体方案，并给出这个方案涉及的各种原则。我们会告诉你如何在自己的项目中使用这些实践。我们认为不会有一种一刀切的解决方案可以应对软件开发中的各个方面，更不用说像配置管理和企业系统的运维控制这么大的主题了。然而本书所述的基本内容是可以广泛应用于各种软件项目的，包括大的、小的、高技术要求或短平快的快速收益项目。
在开始实际应用这些原则时你会发现，针对特定场景还需要关于这些方面的更详细信息。本书最后列有一份参考书目，以及一些在线资源链接，你可以在其中找到关于本书中各主题的更详细信息。
序言
马丁·福勒序
20世纪90年代末期，我拜访了Kent Beck，当时他正在瑞士的一家保险公司工作。他向我介绍了他的项目，他的团队有高度的自律性，而一个很有趣的事情是每晚他们都将软件部署到生产环境中。这种具有规律性的部署带给他们很多好处，已写好的软件不必在部署之前无谓地等待，他们对问题和机会反应迅速，周转期很短使他们与其业务客户以及最终用户三方之间建立了更深层次的关系。
在过去10年里，我一直在ThoughtWorks工作。我们所做的项目有一个共同的主题，那就是缩短从想法到可用软件之间的生产周期。我看到过很多项目案例，几乎所有项目都在设法缩短周期。尽管我们通常不会每天发布，但现在每两周发布一次却是很常见的。
David与Jez就身处这场巨大变革之中。在他们所致力的项目中，频繁且可靠地进行交付已然成为一种文化。David、Jez和我们的同事已经将很多每年才能做一次软件部署的组织带到了持续交付的世界里，即让发布变成了常规活动。
至少对开发团队来说，该方法的基础是持续集成（CI）。CI使整个开发团队保持同步，消除了集成问题引起的延期。在几年前，Paul Duvall写了一本关于CI的书。但CI只是第一步。软件即使被成功地集成到了代码主干上，也仍旧是没有在生产环境中发挥作用的软件。David和Jez的书对从CI至“最后一公里”的问题进行了阐述，描述了如何构建部署流水线，才能将已集成的代码转变为已部署到生产环境中的软件。
这种交付思想长期以来一直是软件开发中被人遗忘的角落，是开发人员和运维团队之间的一个黑洞。因此毫无疑问的是，本书中的技术都依赖于这些团队的凝聚，而这也就是悄然兴起的DevOps运动的前兆。这个过程也包括测试人员，因为测试工作也是确保无差错发布的关键因素。贯穿一切的是高度自动化，让事情能够很快完成而且没有差错。
为了实现这些，需要付出努力，但所带来的好处是意义深远的。持续时间长且强度很高的发布将成为过去。软件客户能够看到一些想法快速变成他们可以每天使用的可工作软件。也许最重要的是，我们消除了软件开发中严重压力的一个重大来源。没有人喜欢为了让系统升级包能够在周一的黎明前发布而在周末紧张加班。
在我看来，如果有这样一本书，能够告诉你如何做到无压力且频繁地交付软件，那么显然它是值得一读的。考虑到你们团队的利益，我希望你能同意我的观点。
20世纪90年代末期，我拜访了Kent Beck，当时他正在瑞士的一家保险公司工作。他向我介绍了他的项目，他的团队有高度的自律性，而一个很有趣的事情是每晚他们都将软件部署到生产环境中。这种具有规律性的部署带给他们很多好处，已写好的软件不必在部署之前无谓地等待，他们对问题和机会反应迅速，周转期很短使他们与其业务客户以及最终用户三方之间建立了更深层次的关系。
在过去10年里，我一直在ThoughtWorks工作。我们所做的项目有一个共同的主题，那就是缩短从想法到可用软件之间的生产周期。我看到过很多项目案例，几乎所有项目都在设法缩短周期。尽管我们通常不会每天发布，但现在每两周发布一次却是很常见的。
David与Jez就身处这场巨大变革之中。在他们所致力的项目中，频繁且可靠地进行交付已然成为一种文化。David、Jez和我们的同事已经将很多每年才能做一次软件部署的组织带到了持续交付的世界里，即让发布变成了常规活动。
至少对开发团队来说，该方法的基础是持续集成（CI）。CI使整个开发团队保持同步，消除了集成问题引起的延期。在几年前，Paul Duvall写了一本关于CI的书。但CI只是第一步。软件即使被成功地集成到了代码主干上，也仍旧是没有在生产环境中发挥作用的软件。David和Jez的书对从CI至“最后一公里”的问题进行了阐述，描述了如何构建部署流水线，才能将已集成的代码转变为已部署到生产环境中的软件。
这种交付思想长期以来一直是软件开发中被人遗忘的角落，是开发人员和运维团队之间的一个黑洞。因此毫无疑问的是，本书中的技术都依赖于这些团队的凝聚，而这也就是悄然兴起的DevOps运动的前兆。这个过程也包括测试人员，因为测试工作也是确保无差错发布的关键因素。贯穿一切的是高度自动化，让事情能够很快完成而且没有差错。
为了实现这些，需要付出努力，但所带来的好处是意义深远的。持续时间长且强度很高的发布将成为过去。软件客户能够看到一些想法快速变成他们可以每天使用的可工作软件。也许最重要的是，我们消除了软件开发中严重压力的一个重大来源。没有人喜欢为了让系统升级包能够在周一的黎明前发布而在周末紧张加班。
在我看来，如果有这样一本书，能够告诉你如何做到无压力且频繁地交付软件，那么显然它是值得一读的。考虑到你们团队的利益，我希望你能同意我的观点。
媒体评论
对本书的赞誉
如果你需要频繁地部署软件，那么本书就是你所需要的。采用本书所描述的实践会帮助你降低风险，克服工作的乏味，并增强信心。我会在我所有的项目中使用本书所描述的原则与实践。
——Kent Beck，三川研究室
不管你的软件开发团队是否已经明白持续集成就像源代码控制一样必不可少，本书都是必读之物。本书不可多得地将整个开发和交付过程放在一起进行诠释，不仅提到了技术与工具，而且提供了一种理念和一些原则。作者讲述的内容从测试自动化到自动部署不一而足，能够满足读者的广泛需求。开发团队中的每个人，包括编程人员、测试人员、系统管理员、DBA和管理者，都应该读一读这本书。
——Lisa Crispin，Agile Testing: A Practical Guide for Testers
and Agile Teams的作者之一
对于很多组织来说，持续交付不仅仅是一种部署方法，它对于开展业务也是至关重要的。本书展示了如何在具体环境中让持续交付成为现实。
——James Turnbull，Pulling Strings with Puppet: Configuration
Management Made Easy的作者
这是一本清晰、准确、精心编写的书，力求让读者明白发布过程究竟应该是什么样子。作者以渐进的方式一步步地阐述了软件部署中的理想状态与障碍。本书是每位软件工程师的必备读物。
——Leyna Cotran，加利福尼亚大学欧文分校软件研究所
Humble和Farley阐明了是什么使快速成长的Web应用取得成功。曾经颇具争议的持续部署和交付已经成为司空见惯的技术，而本书出色地讲述了其中的方方面面。在很多层面上，这都是开发和运维的交点，而他们正是瞄准了这一点。
——John Allspaw， Etsy.com技术运营副总裁
The Art of Capacity Planning和Web Operations的作者
如果你的业务就是构建和交付基于软件的服务，你一定会从本书清晰阐述的理念中受益。而且，除了这些理念以外，Humble和Farley还为快速可靠地进行软件变更提供了一份卓越的“剧本”。
——Damon Edwards，DTO Solutions总裁，dev2ops.org网站主编之一
我相信，做软件的人拿起这本书，翻到任意一章，都会很快得到有价值的信息。如果从头到尾仔细阅读，你就能根据所在组织的具体情况对构建和部署过程进行简化。我认为，这是一本关于软件构建、部署、测试和发布的必备手册。
——Sarah Edrie，哈佛商学院质量工程总监
对于现代软件团队来说，显然持续交付就是持续集成的下一步。本书以不断为客户提供有价值的软件为目标，通过一套明确且有效的原则和做法使这一目标的实现成为了可能。
——Rob Sanheim，Relevance公司技术骨干
如果你需要频繁地部署软件，那么本书就是你所需要的。采用本书所描述的实践会帮助你降低风险，克服工作的乏味，并增强信心。我会在我所有的项目中使用本书所描述的原则与实践。
——Kent Beck，三川研究室
不管你的软件开发团队是否已经明白持续集成就像源代码控制一样必不可少，本书都是必读之物。本书不可多得地将整个开发和交付过程放在一起进行诠释，不仅提到了技术与工具，而且提供了一种理念和一些原则。作者讲述的内容从测试自动化到自动部署不一而足，能够满足读者的广泛需求。开发团队中的每个人，包括编程人员、测试人员、系统管理员、DBA和管理者，都应该读一读这本书。
——Lisa Crispin，Agile Testing: A Practical Guide for Testers
and Agile Teams的作者之一
对于很多组织来说，持续交付不仅仅是一种部署方法，它对于开展业务也是至关重要的。本书展示了如何在具体环境中让持续交付成为现实。
——James Turnbull，Pulling Strings with Puppet: Configuration
Management Made Easy的作者
这是一本清晰、准确、精心编写的书，力求让读者明白发布过程究竟应该是什么样子。作者以渐进的方式一步步地阐述了软件部署中的理想状态与障碍。本书是每位软件工程师的必备读物。
——Leyna Cotran，加利福尼亚大学欧文分校软件研究所
Humble和Farley阐明了是什么使快速成长的Web应用取得成功。曾经颇具争议的持续部署和交付已经成为司空见惯的技术，而本书出色地讲述了其中的方方面面。在很多层面上，这都是开发和运维的交点，而他们正是瞄准了这一点。
——John Allspaw， Etsy.com技术运营副总裁
The Art of Capacity Planning和Web Operations的作者
如果你的业务就是构建和交付基于软件的服务，你一定会从本书清晰阐述的理念中受益。而且，除了这些理念以外，Humble和Farley还为快速可靠地进行软件变更提供了一份卓越的“剧本”。
——Damon Edwards，DTO Solutions总裁，dev2ops.org网站主编之一
我相信，做软件的人拿起这本书，翻到任意一章，都会很快得到有价值的信息。如果从头到尾仔细阅读，你就能根据所在组织的具体情况对构建和部署过程进行简化。我认为，这是一本关于软件构建、部署、测试和发布的必备手册。
——Sarah Edrie，哈佛商学院质量工程总监
对于现代软件团队来说，显然持续交付就是持续集成的下一步。本书以不断为客户提供有价值的软件为目标，通过一套明确且有效的原则和做法使这一目标的实现成为了可能。
——Rob Sanheim，Relevance公司技术骨干
