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

AlexQin

创建正确的产品

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

AlexQin

改进了生产力和效率

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

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

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

AlexQin

可靠的发布

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

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

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

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

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

AlexQin

改善的产品质量

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

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

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

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

AlexQin

更高的客户满意度

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

AlexQin

挑战

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

AlexQin

组织结构上的挑战

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

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

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

AlexQin

流程上的挑战

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

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

AlexQin

技术上的挑战

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

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

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

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

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

AlexQin

致谢

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

参考

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