大规模代码构建技术实践

简介: 在云效持续集成持续交付专场直播中,阿里技术专家何卫龙为大家带来了《大规模代码构建技术实践》的分享。本次分享主要从持续集成的背景,持续集成平台的演进过程,以及如何进行大规模持续集成构建三部分展开,内容精彩,不容错过。

在云效持续集成持续交付专场直播中,阿里技术专家何卫龙为大家带来了《大规模代码构建技术实践》的分享。本次分享主要从持续集成的背景,持续集成平台的演进过程,以及如何进行大规模持续集成构建三部分展开,内容精彩,不容错过。


以下内容根据讲师PPT和视频整理而成。



什么是持续集成?


大师Martin Fowler认为持续集成是一种软件开发实践,在实践中团队开发成员会频繁的进行任务的集成,通常每个成员每天都会集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建来验证,从而尽快地发现集成错误快速进行修复。


e413bc5d64c628b2191ad4070f38bdf2578f0b02 


如上图所示,一个完整的持续集成环节包括:首先项目经理创建一个项目,将项目成员添加到项目中;开发人员在项目中拉取开发分支进行代码开发,在开发过程中,开发人员将代码提交到代码仓库(如SN、GIT);后端的持续集成任务会定时扫描代码仓库,如果发现代码有变更,马上触发一次CI构建,一次CI包括源码下载、代码编译、静态扫描、单元测试、覆盖率分析、sona检查、环境打包部署、自动化用例执行等;再以消息的形式反馈结果给代码提交人或者项目关注人。消息的形式有两种,一种是即时消息,如阿里内部的旺旺、钉钉,让开发人员第一时间收到CI结果概况,如有问题,可以进行快速修复;另一种是邮件通知,可以看到CI结果详情,帮助问题的定位和跟踪,有益于驱动大家修复问题。


持续集成的优势


持续集成有哪些好处呢?


 

087cbfb94d80aaffaa10f8888c2e3303acf106ae 


首先来看一幅图,大家应该都比较熟悉,冰山一角,如果把它移植到研发测试流程上面来讲,我们看的到的冰山,就好比开发阶段发现的Bug,比起海面以下的冰山,简直就是小巫见大巫。因此,持续集成给我们带来的直接好处,就是不断的发现海面以下的Bug,让我们能在开发阶段尽可能多的解决问题;其次,Bug越往后面发现,处理它的成本会越高,付出的代价也越大,因此,持续集成能帮助到我们降低项目研发成本;最后,如右侧图片所示,当持续集成不断的完善项目时,会潜移默化的推动着我们测试前移的动作,从没有集成的1,到集成初期的2,最终不断完善的集成3,成本越来越低、代码质量越来越高、发布时间越来越短 、从而使产品的品质越来越好。


持续集成涉及整个项目生命周期的人员,包括需求方、开发、测试、产品经理等。对于开发人员,他们希望能有单测、覆盖率、findbugs、sonar等自动化集成工具,尽早发现缺陷,这样流入测试环节的问题就会变少,从而保证代码质量;对于测试人员,他们希望尽早集成发现缺陷,提高待测质量,降低项目风险;产品经理则希望项目能按期、保质保量的安全上线。因此我们需要一个持续集成平台来保障上述利益。

 

平台演进


下面来介绍一下平台演进的过程。


c2c18d9883c0877daa7a4921d2b19ed238d206aa 


主流的持续集成工具主要有:


  • 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功能扩展。


f65c5327b6035a2831191fedd1d52fe0575e6e95 


对于小团队而言,Jenkins完全可以满足需求了,但是对于一个成百上千,甚至更多人的团队来讲,就显得有点弱了。第一,Jenkins不能自动创建Jenkins任务,必须在Jenkins平台上手工创建,大大降低了集成效率,而且需要大家都掌握创建Job的方法以及Job上的配置,不利于工具推广;第二,其数据显示不能定制化,如果想要集成数据在一个页面上显示,那么Jenkins是无法满足这个要求的;第三,数据不能持久化,目前Jenkins的数据是通过文本的方式保存的,而且量很大,不利于数据维护和后续的数据分析;第四,执行机掉线没有报警功能,不会及时通知管理员及时处理;第五,数据反馈机制比较单一,Jenkins仅支持邮件的方式进行发送通知;第六,通过项目信息查询任务困难,Jenkins没有项目的维度,只有Job的维度,不方便查找。


cdb350934f82268d16a2618d9ce21dc667f8a270


 

因此,单测集成平台Amon应运而生,它始于2012年,目前已有10多家公司,正在使用这一产品。Amon的优势在于其任务全自动构建,并支持大规模集成、数据持久化,具有丰富的报表和多维度的数据分析,Amon和Jenkins详细功能对比如上图所示,这里不再一一叙述。


dac0b8468c443e29b4e8f19dd155f0f2070a2969 


我们针对Jenkins插件进行了新增和修改,以便它们适应于Amon,主要包括:


  • Maven pom内容修改插件,它能满足一些特定功能;
  • Maven多模块构建插件,支持多路径发现pom文件;
  • MQ构建结果通知插件,它能够通过消息的形式发送到平台;
  • Hosts修改插件,以此支持特定服务的测试;
  • Cppcheck编译扫描结果插件;
  • Antx文件自动生成插件;
  • 支持cobertura结果合并插件;
  • 支持cobertura增量覆盖率插件;
  • 支持jshint扫描插件
  • 支持多执行机空间清理插件
  • Sonar-runner自动找java路径

 

集成实践


目前,阿里内部集成状况是支持10w+的日均构建数,平均每秒发生四次构建,这是一个非常庞大的量。我们的平台是如何来做支撑的呢?


cb26a9ef8f3d1cb1d5db2ae6a3e274d3a50b3a53 


首先,系统通过负载均衡模块将集成任务分配至各集群中;在每个集群中都有大量Jenkins机器来做持续集成构建,它是可以进行横向扩展的,因此我们就能很好地进行大规模的构建。在构建过程中,难免会有一些任务排队等待,这样会导致一些用户等待时间较久。


我们针对这一情况进行了优化:相同集群的Slave可以灵活、自由调度,如果某台Jenkins任务比较吃紧,它就会从最空闲的Jenkins上调度一台Slave过来支持当前的任务构建,以解决任务排队严重的问题。但是,过于频繁的Slave调度势必会影响到系统处理时间和性能。因此,接下来将详细讲解负载均衡做到最优任务分配的原理。


 efd0c600e8f965d70637bc81e7c15b94e48a0516


这里提到的负载均衡和常见的负载均衡还是存在差异的。这里提到的负载均衡任务集成自驱的,也就是其可以定时自动构建,因此,你不太清楚一个任务一天回构建多少次,也不清楚一次构建的时长是多少。在分配任务的时候,可能比较难以选择,如果仍然按照平均分配的方式,势必会形成每个Jenkins上任务个数相同,但是基于每个任务的构建时长和频率都存在差异,这样又会导致一些Jenkins排队非常严重,那么如何解决这个问题呢?


首先需要了解一下Jenkins中的参数:其中n表示任务数、m表示执行机数、T表示最大构建负载(T=m*8*60),如超过最大负载值,任务排队现象会加重;Jenkins第k个任务构建总耗时用tk(tk=任务最近一次构建耗时(分钟)*该任务历史日均构建次数)表示。根据上述参数,可以计算出Jenkins当前的负载值H,公式为:


b2385d1b91df2f0acd1fe46438d4568e54b63afb


利用当前的负载值,进行任务分配,做到最优化:当任务分配到Jenkins时,同时需要增加Jenkins的负载值以及修改该任务的平均耗时和平均构建频率,不断地调整,以便于趋于稳定;当任务关闭时,需要减去相应的时间来调整负载值。该算法的思路较为简单,但实现时比较困难,主要是由于任务的耗时和频率会发生变化,需要实时调整以改变负载值,让集成任务分配到最合适的Jenkins上去。




e38faead9daee6c9183b55daba6b9d153e5b01cd


详情点击>>











相关文章
|
2月前
|
缓存 安全 测试技术
构建高效后端架构的关键技术与实践
【10月更文挑战第11天】 本文深入探讨了后端开发中的几个关键技术点,包括微服务架构、数据库优化、缓存机制、安全性保障以及自动化测试。通过这些技术的应用和最佳实践,可以帮助开发者构建出高效、稳定、安全的后端系统。
41 0
|
4月前
|
人工智能 PyTorch 算法框架/工具
Xinference实战指南:全面解析LLM大模型部署流程,携手Dify打造高效AI应用实践案例,加速AI项目落地进程
【8月更文挑战第6天】Xinference实战指南:全面解析LLM大模型部署流程,携手Dify打造高效AI应用实践案例,加速AI项目落地进程
Xinference实战指南:全面解析LLM大模型部署流程,携手Dify打造高效AI应用实践案例,加速AI项目落地进程
|
4月前
|
人工智能
就AI 基础设施的演进与挑战问题之通过应用核心概念来优化研发过程的问题如何解决
就AI 基础设施的演进与挑战问题之通过应用核心概念来优化研发过程的问题如何解决
|
6月前
|
存储 弹性计算 安全
构建高效企业应用架构:阿里云产品组合实践深度解析
该方案展现了阿里云产品组合的强大能力和灵活性,不仅满足了当前业务需求,也为未来的扩展打下了坚实的基础。希望本文的分享能为读者在设计自己的IT解决方案时提供一定的参考和启发。
363 1
|
6月前
|
jenkins 持续交付 开发工具
高德引擎构建及持续集成技术演进之路
高德引擎构建及持续集成技术演进之路
|
人工智能 Cloud Native 大数据
构建高性能云原生大数据处理平台:融合人工智能优化数据分析流程
构建高性能云原生大数据处理平台:融合人工智能优化数据分析流程
454 0
|
7月前
|
机器学习/深度学习 Cloud Native 持续交付
构建高效机器学习模型的策略与实践构建未来:云原生技术在企业数字化转型中的关键作用
【4月更文挑战第30天】 在机器学习领域,构建一个高效的模型不仅需要深厚的理论基础,还需结合先进的技术手段和策略。本文将探讨一系列提升模型性能的方法,包括数据预处理、特征选择、模型调参以及集成学习等。通过具体案例分析,揭示这些方法如何在实际问题中得以应用,并讨论它们对模型性能的影响。文中还将涉及最新的研究进展,为读者提供前瞻性的指导意义。 【4月更文挑战第30天】随着企业加速其数字化转型之旅,云原生技术已成为推动创新和灵活性的核心。本文深入探讨了云原生架构的原则,包括微服务、容器化、持续集成/持续部署(CI/CD)、以及声明式APIs。分析了这些技术如何共同促进可伸缩性、敏捷性和容错性,同时
|
机器学习/深度学习 存储 人工智能
如何构建可持续的ChatGPT高性能服务器端架构?
与之前的版本相比,GPT-4最大的改进是其多模态(multimodal)能力——它不仅能够阅读文字,还能识别图像。值得注意的是,虽然之前有消息称GPT-4拥有100万亿个参数,但OpenAI并没有证实这个数字。与其相比,OpenAI更强调GPT-4的多模态能力以及其在各种测试中的表现。
如何构建可持续的ChatGPT高性能服务器端架构?
|
运维 前端开发 安全
云端开发在阿里的典型应用场景 | 阿里巴巴DevOps实践指南(十)
云端开发指开发者可基于云平台完成编码、测试、发布等研发流程。一个完整的云端开发平台不仅是提供了一个云端的编码环境,还提供了一整套研发工具和配套设施,让开发者做到在云端即可完成应用程序的需求、编码、测试和运维的全生命周期管理。
云端开发在阿里的典型应用场景  | 阿里巴巴DevOps实践指南(十)
|
调度 机器学习/深度学习 流计算
提效降本:蚂蚁金服如何用融合计算改造在线机器学习
如何实现权益和投放人群的自动匹配,解决系统的冷启动问题,优化转化率和提升用户体验,是一个在线学习的优化问题。
2867 0
提效降本:蚂蚁金服如何用融合计算改造在线机器学习