您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
 
     
   
 订阅
  捐助
持续交付:巨大的益处也伴随着巨大的挑战
 
作者: Lianping Chen 来源:InfoQ 发布于 2015-7-14
1206 次浏览     评价:      
 

持续交付(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让我们能够将新软件发布中内在的商业价值更快地交付给用户,这种能力帮助公司在当今互相竞争的经济环境中脱颖而出,

创建正确的产品

频繁的发布能够让应用程序的开发团队更快地获取用户的反馈,这使他们能够专注于创建实用的特性。如果他们发现某个特性缺乏实用性,他们将停止对它的继续投入,这将帮助他们创建正确的产品。而之前,团队可能会花费大量时间用于创建缺乏实用性的