持续交付：巨大的益处也伴随着巨大的挑战

本文最初发表在 IEEE 软件__ 杂志上， IEEE__ 软件_ 杂志致力于发表严谨的、经过互相审校的文章，专注于当今世界的战略科技。_为了满足运行可靠且灵活企业所面临的挑战，IT__ 经理和技术管理者依赖 __IT Pro__ 获取最先进的解决方案。

持续交付（CD）是一种软件工程方法，团队通过这种方式保持在短周期内生产有价值的软件，并且保证能够可靠地在任何时间发布软件。CD 正在获得越来越多的关注与支持。

CD 的提倡者认为它能够让组织变得更加迅速、高效，并且能够可靠地为市场带来服务方面的改善，并且最终能够在竞争中脱颖而出 1。听起来很棒，但实现 CD 可能会是一个很有挑战的过程，尤其在一些已经形成了固定的发布环境的大公司中显得尤为突出。

在本文中，我将介绍 Paddy Power 是如何实施 CD 的，这是一家书籍制作公司。我将描述我们最终实现的 CD 的能力，它所带来的巨大利益，以及过程中所遇到的各种挑战。这些经验将为其他实践者提供一种实施 CD 的洞察力，而我们所指出的这些挑战将为研究者们在设计自己的研究日程时提供一些有价值的参考。

背景

Paddy Power 是一家发展迅速的公司，它的营业额大约在 60 亿欧元，总共有大约 4 千名员工。它的服务遍及各种管控市场，通过投注点，电话和互联网等方式提供服务。

公司的成长在相当程度上依靠的是不断增长的大量自定义软件应用程序。这些应用包括网站、移动应用、交易与价格系统、实时博彩数据分布系统，以及用于投注点的软件。开发这些软件时用到了各种不同的技术栈，包括 Java、Ruby、PHP 和 .NET。为了运行这些应用，公司的 IT 基础设施由跨越不同地区的数千台服务器所构成。

这些应用是由技术部门负责开发与维护的，部门共有大约 400 名员工。每个软件开发团队的规模取决于应用的规模与复杂度，我们团队的人数在 2 到 26 人之间浮动，而多数团队的规模在 4 到 8 人之间。每个应用的发布周期也各有不同。在过去，每个应用在一年之内的发布次数一般不超过 6 次。在每个发布周期内，我们在周期的一开始收集各种需求，工程师们在几个月的时间内进行开发工作，在周期结束前进行大量的测试与 bug 修复工作。随后开发者将完成的软件移交给运维工程师，以部署到生产环境上。部署过程包含了大量的手工操作。

这种发布模式人为地拖延了在发布周期早期已完成的特性。这些特性能够带来的价值也被浪费了，而且无法获得这些特性的早期反馈。

许多发布过程都是一种“恐怖”的体验，因为这些发布流程没有经过长期的实践，并且其中包含了大量容易出错的手工操作。由手工配置造成的一级故障并不鲜见。此外，发布操作缺乏效率，仅仅是搭建测试环境这一项就需要花上三个星期的时间。

为了改善这种情况，Paddy Power 启动了一个实施 CD 的计划，公司创建了一个共有 8 人组成的专属团队，这些成员都具有两年以上的相关经验。

持续交付管道

因为我们必须要支持多种不同的应用程序，因此我们搭建了一个平台，我们在平台中为每个应用创建了一个 CD 管道。我们团队将负责这个平台的操作与维护，如果某个应用程序的开发团队需要为他们的应用创建一个新的 CD 管道，就由我们来创建。

一个应用程序的管道与另一个应用的管道在阶段的数量与类型上可能会有细微的差别，以实现对该应用的最优化。图一展示了一个管道的示例。

代码提交

代码提交管道能够为开发者所签入的代码提供第一时间的初始反馈。当某个开发者往软件配置管理库中签入代码时，这个阶段就会自动触发，对代码进行编译并执行单元测试。当这个阶段出现错误时，管道会自动中止并通知开发者。开发者随即修改代码，对变更进行结对审查，然后签入新代码。代码提交阶段将会再次被触发，并再次启动管道的运行。如果一切正常的话，管道会自动进入下一阶段。

图 1 —— 一个持续交付管道的示例。推进（promotion）—— 将管道的执行从一个阶段转向下一阶段，可以自动执行或手工执行。随着构建过程通过一个个管道中的阶段，我们对于这次构建能够在生产环境中正常运行的信心也在不断增加。

构建

构建阶段将会再次执行单元测试并生成一个代码覆盖率报告，随后运行集成测试以及各种静态代码分析，并构建出需要发布的内容，然后将待发布内容上传到管理它们的库中，以备部署或分布。之后的每个管道阶段在运行中都会接触到这些待发布内容。在我们使用 CD 实践之前，发布到生产环境中的二进制文件可能会与测试过的二进制文件不同，原因在于我们在每个阶段中都会对这个软件进行一次构建。而每次对软件进行构建都有可能造成不同的结果，我们也经历过由于不同的编译结果造成的 bug。修复这种 bug 是一种非常令人受挫的体验，因为同样的软件能够在开发者与测试人员的环境中运行，却无法在生产环境中正常运行。而 CD 管道能够消除这种 bug，如果发生了任何错误，管道会立即停止并通知开发者，否则它将会自动进入下一阶段。

验收测试

验收测试阶段的主要目的是确保软件完全符合用户的需求。这一阶段将创建验收测试环境，这是一种类似于生产环境的环境，软件将会部署在其中。这一阶段的流程包括加载服务器，对其进行配置（例如配置网络与安全设置），将软件部署在这些服务器上，并配置这些软件。管道将会在这个环境中运行验收测试集。

之前，搭建这个环境完全是手工完成的。在最复杂的一个应用程序中，搭建过程花费了某个开发者两个星期的时间。即使对于小型应用来说，这一过程也要耗费半天时间。

对于新项目来说，搭建过程会更长。开发者需要向基础设施团队申请新的机器，请求 Unix 或 Windows 工程团队配置这些机器，请求网络工程师打开这些机器之间的连接，等等。整个过程会耗费一个月时间。

而在 CD 管道中，开发者不需要再进行这些活动了，管道会自动在几分钟之内完成整个环境的搭建。

与其它几个阶段类似，如果这一阶段中出现了差错，管道会立即停止并通知开发者，否则它将会自动进入下一阶段。

图 2 —— 持续交付的益处。公司受到了这些益处的鼓舞，因此加大了对 CD 的投入。

性能测试

性能测试阶段将衡量代码变更会对软件的性能产生怎样的影响。管道会搭建性能测试环境，在这个环境中执行性能测试集，并将测试结果写入对软件质量进行集中式管理的工具中。

坦白地说，由于搭建一个性能测试环境所需要的精力投入过大，之前我们并没有在开发阶段中进行任何性能测试，我们只在大型发布之前才会执行性能测试。而在 CD 管道中，每个通过了之前阶段的代码提交都会执行性能测试。开发者们能够立即了解代码的变更是否降低了软件的性能。在这个时间点对问题进行诊断以及修复比起在大型发布前修复问题的成本低得多。

手工测试

虽然我们的自动化测试已经很完善了，但有时手工测试还是必要的（比方说测试人员进行的探索性测试，以及业务人员进行的用户验收测试。）2

之前，测试人员必要搭建一个手工测试环境，这让他们感觉十分头疼，因为中间包括了太多的手工、并且容易出错的步骤。

而在 CD 流程中，他们不必再担心这一点了。管道会自动搭建测试环境，并通过电子邮件通知测试人员访问已部署的应用所需的一切信息。

当测试人员对测试结果感到满意后，待发布的内容将从“潜在发布候选”状态推进为“发布候选”状态。此时，软件已经通过了所有质量检测，做好了部署到生产环境的一切准备，只需一个按钮就能够将软件发布到生产环境上。而之前，这种部署有时会因为部署流程和脚本的错误失败。在 CD 中不存在手工部署步骤，并且部署流程和脚本在之前的阶段中已经经过了多次测试。

益处

目前为止，我们已经将 20 个应用程序转移到 CD 流程中了，这些应用是由一个最大的软件开发团队开发的，他们的主要用户是公司内部的业务人员。在所有的软件团队将应用程序转移到 CD 的过程中，他们都实施了一种名为 Kanban 的敏捷方法 3。

在这些应用程序中，CD 体现出了以下 6 点主要的益处（见图 2）

加速了进入市场的时间

发布的频繁大大提升了。在之前，每隔一至六个月才会有一次应用程序的发布。而如今，每个应用平均每周发布一次。某些应用在必要时可以在一天之内进行多次发布。

一个用户故事从概念阶段到进入生产环境的周期从几个月缩减到了 2 至 5 天。

CD 让我们能够将新软件发布中内在的商业价值更快地交付给用户，这种能力帮助公司在当今互相竞争的经济环境中脱颖而出，

创建正确的产品

频繁的发布能够让应用程序的开发团队更快地获取用户的反馈，这使他们能够专注于创建实用的特性。如果他们发现某个特性缺乏实用性，他们将停止对它的继续投入，这将帮助他们创建正确的产品。而之前，团队可能会花费大量时间用于创建缺乏实用性的特性，而他们无法发现这一点，直到下一次重大的发布之后。而在这时，他们已经在这些特性上白白浪费了几个月的时间。

改进了生产力和效率

生产力和效率也得到了极大的改善。比方说，开发者们为了搭建并修复测试环境所消耗的时间曾经达到 20%。而如今，CD 管道会自动搭建这些环境。与之类似，测试人员也曾经花费了大量的时间用以搭建他们的测试环境，而他们现在也不用为此烦恼了。

运维工程师曾经需要花费几天时间的努力才能够将应用发布到生产环境中，而如今他们只需要点击一个按钮就够了，管道会自动将应用发布到生产环境中。

此外，在过去，开发者和运维工程师为了排查和修复由老式发布实践所造成的问题常常要花费大量的精力。而 CD 管道能够消除这些问题，用于修复这些问题的时间与精力可以投入到更有价值的工作中。

可靠的发布

每次发布的风险大大降低了，并且整个发布流程也变得更加可靠。

正如我们之前所说，在 CD 流程中，部署流程与脚本在真正部署到生产环境之前都经过了反复测试。因此，部署流程与脚本中的大多数错误都已经被发现了。

由于发布的频率提高了，因此每个发布中所包含的代码量也减少了。因此找到并且修复存在的问题也变得更加简单，也避免了因它们造成对系统的影响而浪费的时间。

此外，CD 管道能够在某个发布失败时自动回滚，这也进一步降低了发布失败的风险。

工程师们对此表示，与之前相比，他们在发布日所感觉到的压力要小得多了。对他们来说，发布日与平常的任何一天没有区别。

改善的产品质量

产品的质量也得到了极大的改善，整个应用中未关闭 bug 的数量减少了 90% 以上。

在 CD 流程中，代码一旦提交之后，整个代码库会经历一系列的测试。如果在测试中发现任何问题，开发者就会在进行下一项任务前修复这个问题。这种方式就消除了许多可能出现的 bug，在老式的发布实践中，这些 bug 都会被记录在 bug 跟踪系统中。之前，bug 追踪系统中记录了大量的 bug，整个工作的大约 30% 的时间都在进行 bug 的修复。而现如今，基本没有人需要去修复由客户所发现的 bug 了，并且由于 bug 变得非常罕见，团队也不需要使用任何 bug 追踪系统了。

如果确实出现了在生产环境中找到 bug 这种罕见的情况，这个 bug 就会添加到团队的看板板上，并且在几天之内就能够修复并发布。而在之前，客户必须等到下一次的大型发布才能够将这个 bug 修复，这段时间通常达到几个月。

此外，在生产环境中出现一级故障的可能性也大大降低了。除了我们所陈述的原因之外，CD 管道也消除了由于手工配置和易出错的实践而造成的错误。

更高的客户满意度

在使用 CD 流程之前，由于质量和发布方面的问题，用户部门与软件开发团队之间充斥着不信任感和紧张感。经理们表示，两者之间的关系如今已经得到了巨大的改进，并且开始建立起了信任关系。

挑战

受到这些益处的鼓舞，公司加大了在 CD 上的投入，我们开始在整个公司内推行 CD 的实施，CD 平台的改进也成为了最高优先度的工作。然而，CD 的实施也面临着相当大的挑战。

组织结构上的挑战

最大的挑战来自于组织结构。发布活动牵涉到公司内的多个部门，每个部门都有自身的利益、自己的工作方式，以及所控制的势力范围。由于各部门之间的目标是相互竞争的关系，因此他们之间总是存在着紧张感。比方说，我们需要访问服务器的 root，而其它团队控制着这种权限。要达到一种解决方案，需要大量的磋商与谈判，往往时间会超过 6 个月。

为了应对这种组织结构方面的挑战，领导团队重新调整了组织结构，以打破团队之间的壁垒，并促进了协作式的文化，情况从此得到了改善。

虽然关于对组织结构进行转变的文章很多 4，但很少、甚至没有什么文章是专注于介绍如何在组织中引进 CD 的。对于这个主题的进一步研究，例如更深入地理解这些挑战，以及开发出能够更高效地处理这些挑战的策略和实践，能够极大地帮助某个组织平稳地过渡到 CD 流程。

流程上的挑战

许多传统的流程会阻碍 CD 的发展。比方说，某个已准备好进行发布的特性通常必须经过某个变更顾问委员会的批准通过，这会使它的发布时间最多延迟 4 天。如果某个特性从概念到准备发布只需要几天时间就能够完成，那么这 4 天时间对于这一特性的整个周期来说是个非常漫长的期限。

为了指出这些传统流程（包含 5 业务部门、软件开发部门以及运维部门等等）需要进行更多的探索，以开发出并验证能够适用于 CD 的其它替代流程。

技术上的挑战

目前还不存在一种健壮的、能够直接使用、并且具备高度自定义能力的 CD 解决方案。因此我们自行开发了一套方案，这个过程的成本很高。如果有工具能够填补这一鸿沟，它将为公司节省大量资源。

在我们创建这个 CD 平台时，我们使用了许多不同的工具与技术作为我们的构建块。避免对提供商的依赖是一个很大的挑战。如果能够在得到广泛接受的标准上开展工作、依赖于开放的 API，并创建一种灵活的插件生态系统将有助于减轻这种挑战。

处理那些无法适应 CD 流程的应用程序（例如大型的、整体性的应用程序）同样也具有很大的挑战性。在整个行业中存在着大量的这种应用。为了理解它们的特性，并找出以及开发出能够处理这些挑战的最佳策略或实践，需要进行进一步的研究工作。

我们乐于通过与研究者和公司近距离的协作以解决前文所述的这些挑战，让更多的组织能够简单地从 CD 中受益。

请参考边栏中的内容以快速了解关于 CD 这方面所做的其它研究。

致谢

我对我的同事 Klaas-Jan Stol 致以深深的谢意，他是本文的审校者。同样也感谢本文的编辑，他们提供了很大的帮助，以及富有见解的留言。本文只代表了我个人的观点，并不代表我的雇主的任何意见。

参考

1. J. Humble and D. Farley，《持续交付：发布可靠软件的系统方法》（Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation）, Addison-Wesley Professional, 2010.
2. C. Kaner, J. Falk, and H.Q. Nguyen, 《计算机软件测试（第二版）》（Testing Computer Software, 2nd ed.）, John Wiley & Sons, 1999.
3. D.J. Anderson, 《看法方法：科技企业渐进变革成功之道》（Kanban: Successful Evolutionary Change for Your Technology Business）, Blue Hole Press, 2010.
4. R. Todnem By, “《组织变革管理的评论》”“Organisational Change Management: A Critical Review,” J. Change Management, vol. 5, no. 4, 2005, pp. 369–380.
5. Rob, Effective IT Service Management: To ITIL and Beyond!, Springer, 2007.

关于作者

Lianping Chen是一位就职于 Paddy Power 的高级软件工程师，同时也是 Lero —— 利默里克大学的爱尔兰软件工程研究中心的一位兼职博士研究员。他的研究兴趣包括软件需求与架构、持续交付、DevOps 以及软件产品线。Chen 获得了西北工业大学软件工程学科的硕士学位。可以通过 lchen@paddypower.com 联系他。

本文最初发表在 IEEE__ 软件杂志上， IEEE__ 软件_ 杂志致力于发表严谨的、经过互相审校的文章，专注于当今世界的战略科技。_为了满足运行可靠且灵活企业所面临的挑战，IT__ 经理和技术管理者依赖 __IT Pro__ 获取最先进的解决方案。

查看英文原文： Continuous Delivery: Huge Benefits, but Challenges Too