持续交付

90 年代后期，我去拜访了当时在瑞士一家保险公司工作的 Kent Beck。他带我参观了他的项目，他的高度自律的团队的一个有趣之处是，他们每天晚上都将软件部署到生产环境中。这种定期部署给他们带来了很多优势：编写的软件在投入使用之前不会毫无用处地等待，他们可以快速响应问题和机会，快速的周转使他们、他们的业务客户和他们的最终客户之间建立了更深厚的关系。

在过去的十年里，我在 Thoughtworks 工作，我们项目的共同主题是缩短从想法到可用软件的周期时间。我看到了很多项目故事，它们几乎都涉及到坚决缩短这个周期。虽然我们通常不会每天都将软件交付到生产环境中，但现在团队每两周发布一次版本是很常见的。

Dave 和 Jez 一直是这种巨变的一部分，积极参与了构建频繁、可靠交付文化的项目。他们和我们的同事已经将那些每年都在努力部署软件的组织带入了持续交付的世界，在这个世界里，发布变得司空见惯。

这种方法的基础，至少对于开发团队来说，是持续集成 (CI)。CI 使开发团队保持同步，消除了由于集成问题造成的延迟。几年前，Paul Duvall 在本系列中写了一本关于 CI 的书。但 CI 只是第一步。已成功集成到主线代码流中的软件仍然不是在生产环境中运行并发挥作用的软件。Dave 和 Jez 的书从 CI 开始，处理“最后一公里”的问题，描述了如何构建将集成代码转换为生产软件的部署管道。

这种交付思维长期以来一直是软件开发中被遗忘的角落，落入了开发人员和运营团队之间的空白地带。因此，这本书中的技术依赖于将这些团队聚集在一起也就不足为奇了，这是新兴但不断发展的“DevOps”运动的先兆。这个过程还涉及测试人员，因为测试是确保无错误发布的关键要素。贯穿始终的是高度自动化，因此可以快速且无错误地完成工作。

完成所有这些工作需要付出努力，但好处是巨大的。漫长、高强度的发布已成为过去。软件客户看到想法迅速转化为他们每天都可以使用的有效代码。也许最重要的是，我们消除了软件开发中最大的压力来源之一。没有人喜欢在周末紧张地试图在星期一到来之前完成系统升级。

在我看来，一本书可以告诉你如何频繁地交付软件，而不会像往常那样承受压力，这是一本必读之书。为了你的团队，我希望你同意。