腾讯研发效率领先的秘密:高效率的工具




在5月5日的DevOpsDays Beijing,腾讯CODE平台产品经理mars分享介绍了腾讯研发工具体系,并通过两个研发过程中的实践案例,说明DevOps理念对于研发过程的优化作用,本文是这次分享内容的整理和延伸。


一、 腾讯拥有业界领先的研发效率

平均每研发人员单位时间释放出的产品能力,即“研发效率”。


根据腾讯3月份最新发布的公司介绍,腾讯大约有15,000名研发人员。但是,腾讯却有几乎最为广泛的业务线。在日常生活中,每个人都可以感受到腾讯产品的覆盖宽度。更为甚之,腾讯还有著名的“内部赛马”文化,同一类产品可能有多个团队竞争,这意味着集团的产品线要有多份的研发能力以供赛马。在这一切的背后,必须以高效的研发能力来应对保障。


研发效率是是指单位研发人员负责输出的产品能力,统计上就是集团公司整体的产品能力,除以整家公司技术族人数。


那么,究竟是什么使腾讯拥有如此高效的研发能力呢?有以下几点因素:


  • 人的因素

在腾讯,有上万名优秀的技术人员,感谢他们心怀梦想的工作,为企业和社会做出了重要贡献。


  • 敏捷文化

在腾讯,敏捷早已深入骨髓,已经是一种自发的行为。公司无需刻意强调,团队已然践行。


  • 研发工具自动化

研发链上,腾讯具备完整的去中心化的工具体系。在这个体系中,自动化和便利性同等重要,并通过去中心化的机制保证组织末梢上的业务效率。


  • 质量保障能力

腾讯有非常高效的质量控制能力——高效率的质量团队、高效率的质量工具和高效率的方法论。


二、腾讯研发工具链

腾讯特有去中心化的研发工具体系,平台之间使用松耦合的方式互相集成。


下图中列出的工具系统大约占到腾讯内部工具平台的1/8左右。若从圆心点画每一条射线,都能找到一个完整的工具链。从图中可以看出,有些工具平台是公共的,而其他一些则是与业务相关的。

(腾讯研发工具链示意图)


来看一下集团层面的公线工具。


腾讯的代码管理和需求管理有统一的平台,也就是说腾讯的源代码统一由CODE平台负责管理,其中主要是腾讯自研的Git平台,而需求规划系统统一由TAPD承担。


除此之外对于DevOps很重要但又很容易被忽略的部分,是企业内部的一些关键设施,比如办公网络、知识管理、安全管理还有就是最最重要的企业IM。


特别是IM,国内在做DevOps解决方案时经常忽略,IM和DevOps系统适当集成,可以组成实时的信息传递中枢。IM与全链工具链如何结合是一个可以深挖的课题。腾讯在IM方面已经全面使用企业微信,DevOps有关的各个系统都在实时通知的能力上与企业微信做了内部整合。


(公线工具示意图,虚线内)


再来看一下业务线,虚线内囊括了集成、测试、容器、部署、微服务等等工具,可以看到沿着中心每一条线,都能伸展出一条完整的研发和运维工具链。

(业务线工具示意图,虚线内)


其中还有一些比较著名的系统,比如织云、蓝鲸、WeTest、Bugly,在各自的领域上都十分完备,有很好的用户体验。


系统和系统之间的DevOps闭环是通过松耦合的模式互相衔接的:用Hooks触发,再用API相互集成调用。实现一种去中心化的协作能力。


每个业务可以自行选用适于自己的系统,比如一个团队可以使用MIG的RDM做编译,用IEG的CodeCC做静态代码扫描,用QTA或者WeTest做自动化测试,再用织云来发布服务。而不会因为组织架构而拘泥于某一系列的研发工具。


另外每个业务都可以自行定制贴近自己的工具,这样一旦业务形成规模,就能保证研发系统在需求上最快时间的响应,更加利于研发团队快速优化自己的效率。


 三、一个案例

腾讯的研发团队,如何进行项目组织?


腾讯有一个研发项目,因为是个很重要的产品,所以对变更的管理是很在意的,这个团队每月要处理300到500个需求或者任务,项目代码放在腾讯TGit系统上,需求管理用腾讯的TAPD,


具体看一下这个项目是怎么组织的。



这是一个分支策略的示意图,可以看到这个项目采用的多分支的管理模式,每个功能和需求都是在独立的特性分支上开发的。和主流的Github Flow有些不一样,最主要是项目的默认分支不是稳固的,它会在每个月把默认分支重设一遍,比如现在是五月,那么研发Leader就会把默认分支设置成May,所有这个月要发布的功能都向这个分支合并,等到May这个版本发布完之后就启用六月份的June。


这种分支的管理模式的核心思想主要是用发布节奏来组织分支策略,这个模式对多团队合作的大型项目来说有很多的优点。但这个不是本文的议题,有兴趣的同学可以研究下。


本文要谈的重点是左边棕色区域的功能分支,300到500个功能分支,最终要被合入这个月发布的版本中去。可以想象一下临近发版日的时候是什么样子的。


首先,500个功能一定不会是均匀提交的,一般都得到月中或者月末才提交,因为这个月先要沟通需求,需求沟通PK差不多了,开发再去实现,实现完开发自己还要做些调试和测试。所以一个月月末的时候,这些分支的合并压力就会很大。500个功能,假设核心团队的三个技术Leader负责合入把控,就那么几天时间,每个合并遇到问题还要和团队一个一个沟通……别的事就没法做了……


所以大型研发团队的痛点,所有的矛盾和解决方案都指到了分支的合入控制这个点上。那么这个团队怎样解决的呢?


首先是关联需求

在发起合并请求的时候,直接在描述里粘贴对应的需求链接,后台有一个脚本会用正则判断链接是否存在,格式是不是正确。


如果没贴链接或者链接不对,脚本就会自动调用Git平台的接口,阻止下一步操作,像左图这样显示合并被阻止,同时自动用评论提示缺少需求链接,就是下图的样子。


在需求一侧也可以控制这个功能是否可以合入。下图的提示意思就是要在需求管理平台,标记需求单位“可合入”的状态,这个合并请求才能放行。



再来看在合并时质量自动化改进

同样的,利用代码平台的接口,通过自动化脚本,可以实现质量的自动化能力。


可以看到这里构建是用jenkins,测试是用团队自己调用的测试工具和静态检查工具完成的。


如果编译和自动化测试没通过,合并请求也会被阻止,直到开发人员推送了能测试通过的版本,才会放行。



在合并请求的列表上,直接显示了合并请求的检测状态。可以看到每一个合并请求,后面都自动跟了检测状态,绿色的对号或者红色的叉子,这对项目管理人员是很友好的,红色的可以直接跳过不看了。


四、质量控制流程设计的三个要求

自动化、感知能力、控制能力


第一是自动化,流程必须被设计成全面的自动化。哪怕有一点点操作需要手工执行,到具体研发的场景里就有各种理由被遗忘,所以要尽可能保证全流程都是自动化无人工操作的,这里有三小点,自动触发,自动检测,还有自动上报。


第二个要点是感知能力,这里面主要谈的是信息流。如何让研发团队有能力了解和自己去把控质量,那么一定要把信息流做到位,要让研发团队,特别是和这段代码有关的相关人,清晰的知道整个质量验证的进度情况。信息流,主要解决的是沟通的问题,如果信息流做的不好,沟通基本靠嘴,那么效率是非常的低的。


这里也有三个小点,是实时、可追溯、可配置。可配置的意思主要的目的是信息泛滥。


第三点讲控制,就是如何防止低质量的模块被发布,那么流程上就要能自动截断低质量模块的发布,这里面我们提到的解决方法是拦截合并,控制关键分支。当然这里有一个前提,是代码管理系统必须要有拦截功能。


回过头来看从编码到发布的流程,在过去,质量检测在发布前能够介入的时机也就有合并前,合入后,封包后三个阶段:


往常这三步需要分开来做,用DevOps思想解决的是,让这几个事情同时完成,形成一个质量验证的快速闭环。在每次合并请求发起和更新的时候,都自动化的把整个事情完整做一遍。这样保证每一个功能合入都是安全可靠的。


真的能实现完全自动化的差不多只有下图红框圈起来这些


五、第二个例子

RDM是腾讯米格(MIG)的集成工具平台,主要功能是移动端应用集成编译和发布管理。


第二个例子来自米格的RDM平台


RDM是支撑MIG旗下所有移动端业务的工具平台,最主要的功能是集成编译,也有一些自动检测和验证的能力。


下图是一张流程的示意图,展示的是集成和质量工具与源代码管理平台的之间接口的互相调用。从分支push开始到静态检测、到构建、到自动的功能测试,集成在一个Pipeline里面。


下图是RDM Pipeline 配置页


Pipeline最先是拉代码,然后是构建打包,检测项有代码风格、Coverity扫描、Sonar扫描,代码重复率等等,编译集成后,还联合有一些移动端的自动化测试平台和工具。


如下图的对话框,每项检测项目都可以设置他们是否能阻断合并请求。


当合并请求发起或者更新时,Pipeline的显示效果如下图


在合并请求的页面上显示检测正在进行,同时企业微信也弹出来提示,说明检测开始了



检测结果附在合并请求的动态墙上,这些都可以事后在代码平台上查询到,实时的结果则通过企业微信推送。


如果检测失败就会阻止合并请求,之后如果开发新提交的代码解决了这些问题,那么这里的合并请求会自动放行。


小结

上面这些例子,都是在合并请求上附加各种各样的集成能力,利用自动化和流程化,来增强项目人员和管理者的感知,达到优化流程的目的。



一方面通过代码平台和IM的能力实现了实时可追溯的信息流。另一方面,通过代码平台阻断低质量模块的合入(这个阻断能力需要代码管理平台支持)。并展示了在研发过程中的端到端打通能力(从代码提交封包测试完成)。

 

六、开源和开放

腾讯研发工具链上工具的开源项目和开放能力


腾讯研发管理工具链的开源做得很早。其中有一些知名项目,例如蓝鲸配置平台(bk_cmdb)和Tars微服务解决方案(Tars),业界已经比较了解,可以在Github的腾讯账号下搜索到。


腾讯研发工具链上开源过的工具和组件:


本文介绍几个冷门项目:

GAutomator



看截图很快能知道是互娱的项目,这个项目是个Unity的自动化测试框架,它是WeTest的其中一个模块,WeTest是个真机测试云的解决方案,用成千上万台不同型号的手机跑各个机型的自动化测试。


Tscancode

同样是来自互娱的TScanCode,做的是静态代码扫描,支持C++和Lua,帮你分析代码中的潜在漏洞。


QTAF

QTA是SNG社交网络质量部出品的自动化测试框架,承担了SNG多数业务包括腾讯云的部分业务在内的自动化测试需求。支持移动APP、Windows程序、网页、服务端、接口多种不同平台的测试任务,开源的部分放出了Android和iOS的测试库插件,分别是QT4A和QT4i,其中QTAF是其核心框架的核心模块。有兴趣交流可以在Github的项目上给项目组提issue。


七、总结

本文通过分享几个研发过程优化的例子,说明了DevOps端到端的思想不仅仅是针对运维的,它还对研发管理,特别是质量控制很有价值,并且能够直接改善研发团队的体验,减少沟通损耗,提高研发效率。同时也介绍了腾讯内部的实现经验。在流程改进上还有很多的路径或者体验可以优化,希望与同行共勉。


后台回复“devops”,获取本文PPT原件



腾讯技术工程官号

腾讯前沿技术 | 产品 | 行业信息交流发布平台

 


  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值