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

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

孙辰星 - Tencent DevOps - DEV - 4 release.pptx

原文发布于微信公众号 - 腾讯技术工程官方号(Tencent_TEG)

原文发表时间:2018-05-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏小程序

小程序,又一个营销趋势,传统企业还不跟吗?

不知道微信小程序?那你真的out了!微信小程序作为微信推出的强大功能,微信小程序在整个互联网中造成了轩然大波!而基于小程序的各种优点,众多企业和商家开始注册小程...

4359
来自专栏CSDN技术头条

Dropbox存储架构:扩展至EB级别的实践

多年前,我们将 Dropbox 称为“魔力口袋”,因为它设计的初衷就是让用户将所有文件放在一个顺手的地方。一路发展下来,Dropbox 已经从一个简单的东西发展...

2886
来自专栏知晓程序

小程序有更新:新增位置、重力和网络三种调试

1092
来自专栏Golang语言社区

游戏研发与运营环境Docker化

在泛娱乐时代,游戏行业特殊的业务特点为技术团队提出了更高的要求,而Docker对游戏研发的运营环境带来了很多好处。发展至今,游戏研发的行业现状是怎么样的?Doc...

2484
来自专栏北京马哥教育

坚持的力量:Facebook向Python3迁移的过程回顾

Python3的使用量在过去几年有了明显增加,但它仍有很长的路要走。使用Python的大公司倾向于在其基础架构上运行Python2.7代码,Facebook也不...

970
来自专栏Forrest随想录

从0到1:蘑菇街运维技术管理体系建设分享(上)

大家下午好!我叫赵成,来自蘑菇街。今天给大家分享的题目是从0到1,蘑菇街运维技术管理体系建设分享。正式开始分享之前,首先作一个简单的自我介绍和公司介绍。我叫赵成...

2702
来自专栏腾讯移动品质中心TMQ的专栏

探索式测试基础系列——生活进阶曲

在探索式测试落地实践中奏出了协奏曲后进入到高级阶段,如何在问题定位和经验积累中发挥作用,也可以理解为在生活达到非常和谐后,如何孕育一个后代并为其提供良好的环境...

1738
来自专栏ThoughtWorks

敏捷实践Showcase的七宗罪|TW洞见

今日洞见 文章作者/图片来自ThoughtWorks:林冰玉,部分图片来源于网络。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公...

2986
来自专栏Danny的专栏

大神级程序员和普通程序员的区别

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/huyuyang6688/article/...

1172
来自专栏WeTest质量开放平台团队的专栏

建一座安全的“天空城” :揭秘腾讯 WeTest 如何与祖龙共同挖掘手游安全漏洞

《九州天空城3D》上线至今,长期稳定在 APP Store 畅销排行的前五,本文将介绍腾讯 WeTest 手游安全团队在游戏上线前为《九州天空城3D》挖掘安全漏...

1700

扫码关注云+社区

领取腾讯云代金券