大规模代码构建技术实践

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

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


以下内容根据讲师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


详情点击>>











相关文章
|
1月前
|
监控 安全 Serverless
"揭秘D2终端大会热点技术:Serverless架构最佳实践全解析,让你的开发效率翻倍,迈向技术新高峰!"
【10月更文挑战第23天】D2终端大会汇聚了众多前沿技术,其中Serverless架构备受瞩目。它让开发者无需关注服务器管理,专注于业务逻辑,提高开发效率。本文介绍了选择合适平台、设计合理函数架构、优化性能及安全监控的最佳实践,助力开发者充分挖掘Serverless潜力,推动技术发展。
64 1
|
2月前
|
机器学习/深度学习 自然语言处理 搜索推荐
大厂 10Wqps智能客服平台,如何实现架构演进?
40岁老架构师尼恩,凭借深厚的架构功力,指导众多小伙伴成功转型大模型架构师,实现职业逆袭。尼恩的《LLM大模型学习圣经》系列PDF,从基础理论到实战应用,全面覆盖大模型技术,助力读者成为大模型领域的专家。该系列包括《从0到1吃透Transformer技术底座》《从0到1吃透大模型的基础实操》《从0到1吃透大模型的顶级架构》等,内容详实,适合不同水平的读者学习。此外,尼恩还分享了多个智能客服平台的实际案例,展示了大模型在不同场景中的应用,为读者提供了宝贵的实践经验。更多技术资料和指导,请关注尼恩的《技术自由圈》公众号。
大厂 10Wqps智能客服平台,如何实现架构演进?
|
4月前
|
人工智能 PyTorch 算法框架/工具
Xinference实战指南:全面解析LLM大模型部署流程,携手Dify打造高效AI应用实践案例,加速AI项目落地进程
【8月更文挑战第6天】Xinference实战指南:全面解析LLM大模型部署流程,携手Dify打造高效AI应用实践案例,加速AI项目落地进程
Xinference实战指南:全面解析LLM大模型部署流程,携手Dify打造高效AI应用实践案例,加速AI项目落地进程
|
4月前
|
机器学习/深度学习 数据采集 分布式计算
构建一个高效的机器学习工作流:技术实践与优化策略
【8月更文挑战第12天】构建一个高效的机器学习工作流是一个复杂而持续的过程,需要综合考虑数据、模型、算法、平台等多个方面。通过遵循上述步骤和优化策略,可以显著提高机器学习项目的开发效率和质量,为业务带来更大的价值。未来,随着技术的不断进步和应用场景的不断拓展,我们有理由相信机器学习工作流将变得更加高效、智能和灵活。
|
4月前
|
人工智能
就AI 基础设施的演进与挑战问题之通过应用核心概念来优化研发过程的问题如何解决
就AI 基础设施的演进与挑战问题之通过应用核心概念来优化研发过程的问题如何解决
|
6月前
|
存储 弹性计算 安全
构建高效企业应用架构:阿里云产品组合实践深度解析
该方案展现了阿里云产品组合的强大能力和灵活性,不仅满足了当前业务需求,也为未来的扩展打下了坚实的基础。希望本文的分享能为读者在设计自己的IT解决方案时提供一定的参考和启发。
367 1
|
7月前
|
运维 Cloud Native Devops
云原生技术的未来展望:构建动态且高效的应用生态系统
【5月更文挑战第25天】 在数字化转型的浪潮中,云原生技术以其独特的弹性、可扩展性和敏捷性成为推动企业IT架构现代化的关键动力。本文将深入探讨云原生的核心组件如容器化、微服务、持续集成/持续部署(CI/CD)和DevOps文化等,分析它们如何共同塑造一个高效、自动化的云计算环境。同时,文章也将对云原生技术未来可能的发展路径进行预测,并讨论如何利用这些技术来应对日益复杂的业务挑战。
|
7月前
|
人工智能 Java C语言
日志 | AI工程化部署
日志在任何一种语言编程中都会涉及到,python中有logging库,java中有log4j。当然C也有日志功能,一般可以用宏和函数来实现。 需要明确下日志的功能,一般会设置一个日志等级,比如trace < debug < info < warn < error < fatal 等,根据设置的等级高低来判断是否显示日志。 【1月更文挑战第1天】
120 0
|
存储 人工智能 运维
多模态流式 AI 编排平台,大规模减少新应用开发成本
多模态流式 AI 编排平台,大规模减少新应用开发成本
730 0
|
Serverless
Serverless——架构对比、工作流程、核心价值、面临挑战
Serverless——架构对比、工作流程、核心价值、面临挑战自制脑图
350 0
Serverless——架构对比、工作流程、核心价值、面临挑战