马丁·福勒序

20世纪90年代末期，我拜访了Kent Beck，当时他正在瑞士的一家保险公司工作。他向我介绍了他的项目，他的团队有高度的自律性，而一个很有趣的事情是每晚他们都将软件部署到生产环境中。这种具有规律性的部署带给他们很多好处，已写好的软件不必在部署之前无谓地等待，他们对问题和机会反应迅速，周转期很短使他们与其业务客户以及最终用户三方之间建立了更深层次的关系。

在过去10年里，我一直在ThoughtWorks工作。我们所做的项目有一个共同的主题，那就是缩短从想法到可用软件之间的生产周期。我看到过很多项目案例，几乎所有项目都在设法缩短周期。尽管我们通常不会每天发布，但现在每两周发布一次却是很常见的。

David与Jez就身处这场巨大变革之中。在他们所致力的项目中，频繁且可靠地进行交付已然成为一种文化。David、Jez和我们的同事已经将很多每年才能做一次软件部署的组织带到了持续交付的世界里，即让发布变成了常规活动。

至少对开发团队来说，该方法的基础是持续集成（CI）。CI使整个开发团队保持同步，消除了集成问题引起的延期。在几年前，Paul Duvall写了一本关于CI的书。但CI只是第一步。软件即使被成功地集成到了代码主干上，也仍旧是没有在生产环境中发挥作用的软件。David和Jez的书对从CI至“最后一公里”的问题进行了阐述，描述了如何构建部署流水线，才能将已集成的代码转变为已部署到生产环境中的软件。

这种交付思想长期以来一直是软件开发中被人遗忘的角落，是开发人员和运维团队之间的一个黑洞。因此毫无疑问的是，本书中的技术都依赖于这些团队的凝聚，而这也就是悄然兴起的DevOps运动的前兆。这个过程也包括测试人员，因为测试工作也是确保无差错发布的关键因素。贯穿一切的是高度自动化，让事情能够很快完成而且没有差错。

为了实现这些，需要付出努力，但所带来的好处是意义深远的。持续时间长且强度很高的发布将成为过去。软件客户能够看到一些想法快速变成他们可以每天使用的可工作软件。也许最重要的是，我们消除了软件开发中严重压力的一个重大来源。没有人喜欢为了让系统升级包能够在周一的黎明前发布而在周末紧张加班。

在我看来，如果有这样一本书，能够告诉你如何做到无压力且频繁地交付软件，那么显然它是值得一读的。考虑到你们团队的利益，我希望你能同意我的观点。