在云效持续集成持续交付专场直播中,阿里技术专家何卫龙为大家带来了《大规模代码构建技术实践》的分享。本次分享主要从持续集成的背景,持续集成平台的演进过程,以及如何进行大规模持续集成构建三部分展开,内容精彩,不容错过。
以下内容根据讲师PPT和视频整理而成。
什么是持续集成?
大师Martin Fowler认为持续集成是一种软件开发实践,在实践中团队开发成员会频繁的进行任务的集成,通常每个成员每天都会集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建来验证,从而尽快地发现集成错误,快速进行修复。
如上图所示,一个完整的持续集成环节包括:首先项目经理创建一个项目,将项目成员添加到项目中;开发人员在项目中拉取开发分支进行代码开发,在开发过程中,开发人员将代码提交到代码仓库(如SN、GIT);后端的持续集成任务会定时扫描代码仓库,如果发现代码有变更,马上触发一次CI构建,一次CI包括源码下载、代码编译、静态扫描、单元测试、覆盖率分析、sona检查、环境打包部署、自动化用例执行等;再以消息的形式反馈结果给代码提交人或者项目关注人。消息的形式有两种,一种是即时消息,如阿里内部的旺旺、钉钉,让开发人员第一时间收到CI结果概况,如有问题,可以进行快速修复;另一种是邮件通知,可以看到CI结果详情,帮助问题的定位和跟踪,有益于驱动大家修复问题。
持续集成的优势
持续集成有哪些好处呢?
首先来看一幅图,大家应该都比较熟悉,冰山一角,如果把它移植到研发测试流程上面来讲,我们看的到的冰山,就好比开发阶段发现的Bug,比起海面以下的冰山,简直就是小巫见大巫。因此,持续集成给我们带来的直接好处,就是不断的发现海面以下的Bug,让我们能在开发阶段尽可能多的解决问题;其次,Bug越往后面发现,处理它的成本会越高,付出的代价也越大,因此,持续集成能帮助到我们降低项目研发成本;最后,如右侧图片所示,当持续集成不断的完善项目时,会潜移默化的推动着我们测试前移的动作,从没有集成的1,到集成初期的2,最终不断完善的集成3,成本越来越低、代码质量越来越高、发布时间越来越短 、从而使产品的品质越来越好。
持续集成涉及整个项目生命周期的人员,包括需求方、开发、测试、产品经理等。对于开发人员,他们希望能有单测、覆盖率、findbugs、sonar等自动化集成工具,尽早发现缺陷,这样流入测试环节的问题就会变少,从而保证代码质量;对于测试人员,他们希望尽早集成发现缺陷,提高待测质量,降低项目风险;产品经理则希望项目能按期、保质保量的安全上线。因此我们需要一个持续集成平台来保障上述利益。
平台演进
下面来介绍一下平台演进的过程。
主流的持续集成工具主要有:
-
Jenkins,它的前身是Hudson ,是一个可扩展的持续集成引擎。它的功能比较强大,支持分布式任务构建。
-
GoCD,一款先进的持续集成和发布管理系统,由ThoughtWorks开发,其前身为CruiseControl,是ThoughtWorks在做咨询和交付交付项目时自己开发的一款开源的持续集成工具,ThoughtWorks专门成立了一个项目组,基于Cruise开发出了GoCD这款工具。使用GoCD来建立起一个项目的持续部署pipeline是非常快的,非常方便,它的不足点是插件较少、开源时间短、用户群体较小;
-
Apache continuum,其安装和配置都较为方便;
-
Strider 是一个开源的持续集成和发布服务器,使用 Node.js 开发;
-
TeamCity是一款功能强大的持续集成(Continue Integration)工具,包括服务器端和客户端,目前支持Java、.Net项目开发,是一款商业软件;
-
Atlassian Bamboo 是一款持续集成构建服务器软件(Build Server)商业软件;
-
Travis CI是一个基于云的持续集成项目,目前已经支持大部分主流语言了,比如C、PHP、Ruby、Python、Nodejs等。和Jenkins类似,Travis CI也是开源的,不过Travis和Github集成非常紧密,官方的集成测试托管只支持Github项目, 不过用户也可以搭建一套自己的方案。
通过对上述持续集成工具的比较,阿里最终选择了Jenkins这一工具,Jenkins作为一款开源软件,有着丰富的插件(目前已达几百个),还可以自定义插件以及修改或增加Jenkins扩展点,来进行Jenkins功能扩展。
对于小团队而言,Jenkins完全可以满足需求了,但是对于一个成百上千,甚至更多人的团队来讲,就显得有点弱了。第一,Jenkins不能自动创建Jenkins任务,必须在Jenkins平台上手工创建,大大降低了集成效率,而且需要大家都掌握创建Job的方法以及Job上的配置,不利于工具推广;第二,其数据显示不能定制化,如果想要集成数据在一个页面上显示,那么Jenkins是无法满足这个要求的;第三,数据不能持久化,目前Jenkins的数据是通过文本的方式保存的,而且量很大,不利于数据维护和后续的数据分析;第四,执行机掉线没有报警功能,不会及时通知管理员及时处理;第五,数据反馈机制比较单一,Jenkins仅支持邮件的方式进行发送通知;第六,通过项目信息查询任务困难,Jenkins没有项目的维度,只有Job的维度,不方便查找。
因此,单测集成平台Amon应运而生,它始于2012年,目前已有10多家公司,正在使用这一产品。Amon的优势在于其任务全自动构建,并支持大规模集成、数据持久化,具有丰富的报表和多维度的数据分析,Amon和Jenkins详细功能对比如上图所示,这里不再一一叙述。
我们针对Jenkins插件进行了新增和修改,以便它们适应于Amon,主要包括:
-
Maven pom内容修改插件,它能满足一些特定功能;
-
Maven多模块构建插件,支持多路径发现pom文件;
-
MQ构建结果通知插件,它能够通过消息的形式发送到平台;
-
Hosts修改插件,以此支持特定服务的测试;
-
Cppcheck编译扫描结果插件;
-
Antx文件自动生成插件;
-
支持cobertura结果合并插件;
-
支持cobertura增量覆盖率插件;
-
支持jshint扫描插件
-
支持多执行机空间清理插件
-
Sonar-runner自动找java路径
集成实践
目前,阿里内部集成状况是支持10w+的日均构建数,平均每秒发生四次构建,这是一个非常庞大的量。我们的平台是如何来做支撑的呢?
首先,系统通过负载均衡模块将集成任务分配至各集群中;在每个集群中都有大量Jenkins机器来做持续集成构建,它是可以进行横向扩展的,因此我们就能很好地进行大规模的构建。在构建过程中,难免会有一些任务排队等待,这样会导致一些用户等待时间较久。
我们针对这一情况进行了优化:相同集群的Slave可以灵活、自由调度,如果某台Jenkins任务比较吃紧,它就会从最空闲的Jenkins上调度一台Slave过来支持当前的任务构建,以解决任务排队严重的问题。但是,过于频繁的Slave调度势必会影响到系统处理时间和性能。因此,接下来将详细讲解负载均衡做到最优任务分配的原理。
这里提到的负载均衡和常见的负载均衡还是存在差异的。这里提到的负载均衡任务集成自驱的,也就是其可以定时自动构建,因此,你不太清楚一个任务一天回构建多少次,也不清楚一次构建的时长是多少。在分配任务的时候,可能比较难以选择,如果仍然按照平均分配的方式,势必会形成每个Jenkins上任务个数相同,但是基于每个任务的构建时长和频率都存在差异,这样又会导致一些Jenkins排队非常严重,那么如何解决这个问题呢?
首先需要了解一下Jenkins中的参数:其中n表示任务数、m表示执行机数、T表示最大构建负载(T=m*8*60),如超过最大负载值,任务排队现象会加重;Jenkins第k个任务构建总耗时用tk(tk=任务最近一次构建耗时(分钟)*该任务历史日均构建次数)表示。根据上述参数,可以计算出Jenkins当前的负载值H,公式为:
利用当前的负载值,进行任务分配,做到最优化:当任务分配到Jenkins时,同时需要增加Jenkins的负载值以及修改该任务的平均耗时和平均构建频率,不断地调整,以便于趋于稳定;当任务关闭时,需要减去相应的时间来调整负载值。该算法的思路较为简单,但实现时比较困难,主要是由于任务的耗时和频率会发生变化,需要实时调整以改变负载值,让集成任务分配到最合适的Jenkins上去。