@gaoxiaoyunwei2017 2018-01-05T16:17:26.000000Z 字数 8515 阅读 537

让大象跳舞，手Q研发体系与工具实践

白凡

讲师 | 潘金赤
编辑 | 白凡

讲师简介

潘金赤
腾讯高级工程师，毕业于华中科技大学，硕士学历。至今已在腾讯工作6年，任研发平台工具负责人。

腾讯内部大家更倾向于根据自己的业务特色做平台的封装，我想以“手Q”为案例看看腾讯内部是如何交付的。
今天的交流主要分为三大话题：

"手Q"平台是什么样子
研发平台工具分享
"手Q"内部怎么落地，给“手Q”带来怎样的效果和效率提升。

根据腾讯公司Q3刚刚发布的财报数据，“手Q”月活已经达到了6.5亿，同时在线达到了2.7亿，同时同时某一个时间点有2.7亿用户在用QQ这里的同时在线包含PC和“手Q”，“手Q”已经占了非常大的比重，超过50%。
除了即时通讯“手Q”还承载着其他的场景，不仅仅是通讯，包括生活、社交。现在大家全公司各个业务都能在“手Q”上面找到入口，这也方便公司内其他的业务，通过“手Q”能够快速的接触到用户，能够让用户快速走到“手Q”，通过“手Q”走到各个业务平台入口。

这里有张“手Q”团队内部的照片，其实是开个玩笑，这个照片也很好的显现出了现在“手Q”团队的特点：

人非常多
每一个版本都像一辆车

那么多人都想往这辆车上挤，赶上这趟车，不能被落下。

“手Q”在版本发布上，面临这些挑战：

横跨公司7大事业群，20多个部门，研发测试超3000人
每个版本300+需求，10万+行代码，5000+测试运力
几亿用户关注
每月一个新版本

我们团队内部是这样的并行开发模式。同时一个时间点可能有三个版本并行滚动。每个版本从需求立项开始，到最终版本发布出去，可能需要3到4个月，因为这样的并行开发，在每一个版本发展时间和间隔一个月到一个半月就有一个新版本可以让用户用。这样既可以刺激用户，让用户有新鲜感，始终有心的客户用。同时让我们每个阶段的每个成员都能够高效的滚动起来，而不需要等着上一步输出之后才可以做下一步的动作。

说到研发模式。我们都是分支开发，每个需求做新功能的时候就会挖一个分支，在上面做需求开发，同时定时同步主干上的变动，当这个需求测试完成，这个分支就会冻结，这个就再也不会动了。主干系统测试，测试完了以后拉一个发布分支，发布可能有其他的问题，会到发布分支。

在分支开发的过程中，“手Q”这么大的规模，这么大的团队，遇到哪些问题呢？这个问题可能不仅仅是“手Q”团队会这样，我相信在公司或者项目的规模达到一定的层级之后，都可能遇到这样的问题。体现在研发阶段可能这四个。

1. 主干上面变动太大，几千人都在开发提交会导致漏合、错合或者把别人的代码覆盖
2. 测试的时候需要频繁的换包，经常测到一半，发现包更新了，需要重新换包来测
3. 主干有时不稳定会导致主干失败，过多提交导致部分定义失败
4. 部署的阶段，涉及20多个部门，经常需要全部确认后才能部署，导致非常部署推进困难低效

为了优化上述问题，我们使用了平台加工具加流程，下面介绍研发平台工具

配置管理系统

配置管理是属于一个项目后面做自动化一切数据的依据，记录所有的版本和分支信息，除此之外还有三大作用：
1. 分支的管理，以前分支都是自己手工拉，或者通过内部的角色配置管理员他来负责拉，这个人也很容易成为单点的瓶颈。现在用这个系统完成分支的创建，所有的分支不允许手工创建，必须是系统申请，这样可以很好的保证我们分支不管是命名，不管是分支的信息、责任人全部明确。同时创建分支的时候还需要做到分支和需求的关联。我拉这个分支是做什么需求的，分支拉进去或者合出去以后要知道。

2. 权限管理。后面谁操作的时候由人给他开权限，这样还是一样的问题，成为单点，或者说人不好评审该不该给你开权限，现在是系统控制，权限必须申请，不准是合需求还是改BUG，否则没有办法拿到“手Q”代码主干权限的。
3. 代码管理，代码管理的功能，拉完分支之后，系统会每天帮我们的分支做一次主干代码同步，也就是说不需要开发自己操作，可以保证分支的代码跟主干的差异最多不超过一天，这样可以保证后面做其他的开发以及代码合入的时候尽可能的少。同时我们针对冲突也有一些冲突处理的规则，开发根据自己制定的规则进行调整。我们也会有敏感文件间的保护，保护合心基础公共的文件。项目整体的解耦做的不够好，所以必须要有这样的机制，保证基础公共文件不被调整。

最后还有一个是根据项目团队成员的信息，控制一旦人走了以后权限能立即收回，而不造成信息泄漏和代码泄漏的问题。

合流系统

合流的意思是把代码从分支上合到主干上，虽然说是非常简单的动作，但其实在实际的项目当中，会遇到非常多的问题。尤其是那么多人，大家都想在同一个时间点完成代码的提交，经常需要睡在公司排队等待版本合流。针对这些乱象，我们搭建这套合流系统来解决出现的问题。
我们从这五个方面去完成合流的效率提升：

第一，建立流程。我们把合流分为三个阶段，满足一定条件以后才可以进行下一阶段的跳转，所有的流程都必须在线上做跟踪和追溯，同时保证每个环节的数据都是落地的。
第二，分支管理，刚刚说了分支管理在配置管理系统已经落地了。我们清楚地看到每个分支计划和实际合入在什么阶段，保证我们所有的合流都是有序的。
第三块，双重验证，双重验证就是合流之前，要完成所有工具的测试。合入之后也要做准测试，保证合之前的质量是没有问题的，合的过程当中没有出其他的差错。
第四，权限控制，把所有主干权限收回来了，大家只能跑到那个阶段排队，轮到你的时候才能合，我们会有一个提醒，比如说15分钟之内来合吧，如果不来权限就收回了。权限给你的时候你还需要快速的合入，我们本来时间限定是1小时，超过1小时就有不断的提醒，告诉你主干时间太长了，出现了什么问题，要不要找人帮忙，或者让后面排队的人合。
第五，过程透明，过程透明的优势在于我不仅仅可以把我们的规则明晰出去，同时让做的不好的团队，他能够向好的团队学习，有了标杆作用之后，促进大家有良性的竞争，不断的优化，这就是合流系统的思路，为合流阶段做的优化。

代码扫描系统

代码扫描有非常多优秀的工具，包括PMD。我们内部的代码扫描工具其实就是把业界的优秀工具实践以及我们内部自研的工具，来做整合，针对内部业务的特性做了适配和改造，在工具的基础上封装了两千多个规则级，这个规则级可以给各个业务不同场景做支撑的，这些各个业务可以单独的定制。

基于那么多工具、规则级的封装，我们要求跨语言、跨平台的完成代码和扫描或者代码静态检查完整的解决方案。现在我们基于这些工具，针对公司内部所有的平台、语言、业务做支持。
主要功能包括:

代码扫描发现问题
代码分析、代码复杂度、逻辑复杂度的统计
功能测试当中输出代码覆盖率信息，协助测试团队提供信息证据

目前这个工具内部业务有60+，每个月平均发现了接近3万个问题，这个问题我们内部统计了一下，包括代码规范，包括空指针包括内存泄漏，这些问题团队内部是最多的，也是需要团队共同解决优化的。

自动化系统

业界有一些重要测试的工具，包括robot，但是并不适合“手Q”或者SNG：

内部业务的改动多，尤其是界面交互的改动是非常频繁的
稳定性非常低，只要有任何一点界面改动之后，这些代码都会废掉。
另外一个包括我们的终端EAT有很多自动的空间，想通过外部的程序去做控件识别是非常困难的。

我们内部研发了一套QTA，其实是整套完整的UI自动化的解决方案，涵盖了PC端、web端、安卓、IOS，也包括协议自动化，这个框架里面全部整合了。
完成了对各个端底层控件的识别和操作，这套框架也把这些控件封装成了对于内部业务来说比较好理解，也比较好做封装的对象。
测试基于这六项写自动化测试的用例，可以操作这些用例。
编写完用例之后，可以通过我们分布式测试的执行引擎。
跑完以后把数据结果汇总到报告平台，这个报告当中可以看到包括执行环境、测试版本，包括每个测试用例的情况，以及测试信息，包括不通过的时候会有截图，会有日志、堆站信息都会展现。
增加监控，比如说某些机器经常测试失败，或者某些用例老是跑不过，这种会给内部告诉你这些问题然后进行优化。

这个是现在接入的报告信息，这里有一份统计数据，QTA这个业务，所有的用例有20000+，测试计划2000多个，每个月执行测试任务7万多次。每个月跑的测试用例总数200多万份，这个量也是非常大的。

也正是有这么大的量，也引申出来另外一个问题，自动化测试必须要有设备，针对“手Q”，比如说“手Q”安卓来说，必须要有安卓的测试机，我们测试机怎么办？

搭建一个机房，故障时跑到机房去查，形象难看
手机钉在墙上查看，但是设备采购和维护成本依然存在

基于这样我们也是做了一个方案，就是安卓虚拟化，去虚拟化安卓的虚拟机，所有测试在虚拟机上面完成，这样我们在测试开始的时候，我们去根据测试的需要去虚拟化对应的操作系统，对应的CPU和内存的需求。在测试完成之后自动收回，这个跟早上说的构建跟docker的方案有点类似的，这个是针对终端的虚拟化。

这样的虚拟化之后我们还能够通过wep方式，制订某一台安卓的虚拟机完成UI操作或者是命令行操作，或者是直接上传，我们可以直接通过本地，坐在电脑前，通过一个网页就可以看到某一台机器测试情况是什么样的。

与实体机相比，虚拟机有明显好处：

节省了设备采购和维护成本
实体机器跑的时间长了以后会劳损，电池会鼓胀，导致稳定性下降

所以现在我们在“手Q”项目内部的，或者SNG内部更多的自动化测试还是与虚拟机完成的。

专项测试系统

专项测试我认为在腾讯或者“手Q”团队做的非常深入的一个领域了。专项测试涵盖资源的性能、交互的性能、稳定性、兼容性、安全方面的测试。我们团队针对这里的每一块领域，都有一整套比较完整的解决方案，在版本上线前，甚至版本发布或都能够帮助业务团队定位以及分析各个环节当中出现的性能问题。这里也介绍两个团队当中用的比较有代表性的两个工具。

New Monkey，这个是在Monkey工具的基础上研发，有更多符合我们的优势：
- 保证更多有效的控件平均的被操作，不像Monkey操作完全是随机，以至于可能有一些空间在入口在没有那么浅的情况下操作到
- 通过触发式的脚本，根据我们结果不同深入的挖掘，保证更深层次的控件也都能够操作到
- 通过稳定性测试，同时帮助发现性能的问题，和性能监控的SDK技术结合
- 开发了随身版，大家不需要把这个测试固定到某一台机器上执行，每个开发同学自己带一台手机装个随身版，随时随地跑稳定性测试，这样大家发现问题的成本，或者说大家进行测试的成本就越来越低了
APM是属于一个资源类性能、交互类性能数据采集和分析的SDK。
- 各个业务接入这个SDK以后，可以很方便的完成比如说我在某个页面或者说某一个控件操作时的时延，或者说用户在使用否个功能的流畅度，是否有丢真的统计上报。
- 这个数据也是整合到“手Q”和SNG其他内部产品的线上版本。如果说当线上的版本有大量用户反馈说我们这个版本很卡，不好用的时候，可以通过后台开启开关，然后来完成用户在操作时候我们内部函数调用之间以及在渲染之间的时间差、或者时延或者内存以及CPU分配的情况。能够知道当前的卡顿到底产生在哪，从而给开发更好的定位问题的渠道。
  
  坦白说，专项这块内容实在是太广，里面每一点个技术点都在外面做过专题分享。包括我看到高效运维社区打的广告，我就看到了一个熟人，也是参加过这样一些分享的，这块内容是非常多的，我估计我在这里讲一天一夜都不一定讲得完，也不一定他们讲的专业，这里我就不深入介绍了。
  也为了表示我对专业项目团队的钦佩和歉意，我就给他们打个广告，这是专项团队的著作，是现在他们的技术实践以及在项目当中不仅“手Q”还有其他的项目当中经典的案例来汇集出来的干货。

众测平台

众测是机遇众包概念的产品，希望借助于外面更多人的力量帮我们内部达成某些任务或者目的。方式就是内部业务，通过给众测平台提供业务，外面可以通过web或者APP领取，并且提交测试给他们反馈，我们根据他们反馈有效性，看看是不是真的值得改善的需求点，同时给到内部业务做持续的优化，同时由这个平台完成用户的奖励发放。这一整套就是这个众测平台完成的工作。

通过这个众测可以达到几个目的。

第一，兼容性测试，因为我们内部做测试，包括之前也聊了一些测试团队，他们机型再怎么丰富，毕竟考虑到成本问题，比如说像我们之前用到大连兼容预测团队，机型就是200多，但外面用户机型是千差万别，通过众测的模式可以很好的实现兼容性的问题。
第二，功能用例情况，每个用例手工跑发是非常耗时的，是否可以把没有发生太大改变的用例，或者基础的功能用例我们丢给外部跑，让他帮我们保证这个功能没有问题，我们内部就可以根据其他的策略，比如说精准测试，或者是其他的比如说freetest（音）。
第三，这里单独列一点，就是IOS灰度困难的问题，以前IOS要灰度就只能通过一个渠道，就是越狱用户，现在IOS用户越狱人数都越来越低，大家不愿意做越狱了，这样我们内部产品越狱的难度非常大。通过众测我们跟苹果做对接，通过体验版本的下载，保证我们IOS的灰度其实是还能够按照比较正常，而且至少不和苹果相冲突的方式进行。
第四，现在比较火的我们搞AI，AI一定需要大量的素材，这个素材怎么采集和标注，大家也可以通过众测，众测的价值就是人多力量大。

这就是我国众测平台以及APP的介绍。这个众测做了差不多一年多两年的时间，目前帮我们内部投放了两千多次任务，平均每个月都有三十多个业务，已经累积帮我们发现了至少2000多个BUG。采集标注的素材就是上方的素材了。这是众测。

CIS

来JUCC不介绍“CIS”集成好像不行，我觉得我们内部集成做的挺弱的，有了KK以及他的团队在Jenkins这块不懈的努力。我觉得各个团队都可以在Jenkins的基础上快速的搭建起一套自己的急症系统，甚至不做任何的开发，我们之所以做这个界面，是想让用这个平台的人尽可能能拿到直接用。

第一，是自动、快速启动构建，
第二，提供编译产出，
第三，上下游的串联，上游串联跟开发结合了，我当前构建是哪一个基线，这个基线完成了哪些内容的开发，构建的什么功能在这里可以看到。下游就是跟下面合流以及发布做一些结合，会拿这个结果作为下一步数据的输入。
第四，质量的运行，当出现失败的时候，就能够在整个团队当中快速的完成周知。因为以前构建老失败，我们这里放一个电视，看到红色的时候麻烦去解决。现在成功率比较高了，大家也不怎么用了。
第五，效率统计，能够很快速的知道我构建的排队、耗时以及过程当中的成功、失败的信息统计，我们把几百个代码的编译从40分钟缩短到10几分钟的过程，这里不详细介绍了，也是很复杂的故事了。

晨报

我们希望每次构建就能够立即触发编译，立即触发自动化测试，但在“手Q”内部这样做不到：

一方面是因为代码确实代大了，编译慢，测试花的时间有点长
另一方面也确实是说从成本上面考虑，我们不太可能让每一个代码提交都能够编译完成测试

我们做了一个定时监控，每天晨报监控一次。这个晨报相对于在我们拉分支或者他们在配置管理系统上面创立这种分支的时候就创建好，完成这些测试，这些测试可以帮你发现主干或者分支上面的版本质量。这个测试结果同样可以用于后面场景的复用了。

其实基本上我们内部用到的比较有特色的研发平台都已经做完介绍了，这里也想和我们DevOps里面有一点想做匹配，我们怎么样能够保证整个研发环节，或者说包含我们发布出去的代码质量能够给到内部很好的正向反馈，能够持续的让内部项目持续优化，或者说把一些问题转化成新的需求，能够快速的体现出来。

过程度量和预警

这是整个研发环节全流程数据的全景视图，可以帮我们分析，各个需求阶段的需求怎么样，是否按照进程完成发布。

同时我们代码提交的频度、走势。以及某些文件是否属于频繁操作文件，这个文件是不是该去解耦了。

测试阶段我们看到根着测试进行，我们BUG有没有收敛，这个有没有质量风险，以及我们构建的时候根据构建的时长，我们要不要做构建编译的优化，或者说增加构建的集群。

在部署的阶段我们看到发布的一些当前进展，以及当前发布的效率，我们也能看到在线网质量的反馈。

这个是各个阶段的视图，同时我们还能支持把各个阶段的关键数据做到一个衡量的指标，各个业务的团队可以来根据这个指标配置一个阈值。

也就是说当我研发过程当中，某一个指标超出阈值会发出告警，预示着这个系统有风险了，我需要尽早的规避。
比如说现在某个开发的BUG有超过5个，就很清晰的知道目前是什么状态，需不需要有一个结构或者计划的调整。

研发平台实践

在研发环境当中那么多流程，那么多平台，其实他们就有点像是一个流式的，在各个环节和下一个环节都是通过数据或者说一些过程阶段性的输出，比如说安装包，或者说一个配置文件信息，来流式的向下传递，来保证我们各个环节的信息都是串联的。

能由前面的环节推动下面的环节，包括监控这里一样可以把数据反馈到TAPD，这个是内部相关管理的平台，把监控数据转换成新的BUG进行下一个版本的迭代和滚动。

这样带来的好处也是非常直接的，比如我们说让配置管理员做这个工作，现在有这样的系统，可以让配置管理员的工作节省出来了，能提升质量也能减少测试人员不断做手工测试的成本。同样我们所有的数据都在线上跑的话，这个数据是有据可查的，可跟踪的。而且我们最终在刚刚的发布系统，通过这样的系统我们能够让各个业务团队的人都能够知道，我需要做什么，到某个时间点了，我要做什么事情，以及我这个时间点卡了多久。其实可以让大家都能知道我做这个事情的效率进度怎么样，而且不断的反思和完成优化。

这个也是带来的一个很直观的效果。这里还想额外讲一下，因为之前我们提到，我们在做优化的时候，一定是平台加工具、加流程，刚才介绍的是平台和工具，我们是怎么在流程上完成优化的呢？这里我拿“手Q”合流这一点做一个流程介绍上面的分享。

刚才看到有合流系统，有自动化测试、代码扫描工具为这个合流过程做的加速。但在流程上，其实在合流这里体现的非常明显，刚才说合流分三个阶段，第一个阶段要完成这么多检查，但这个检查当中其实除了需求状态检查、分支同步检查、工具的检查以外，这些是必须要做的，就是所有在合流之前全部要做的。但还有很多是流程上做考虑，比如说代码何如资格检查，什么是何如资格检查？每个新同学进入“手Q”项目，在允许参与“手Q”开发过程之前，他必须要经过培训、考试，而且考试必须达到一百分。你必须得知道你合代码怎么合，遇到代码怎么结，这些点必须考试通过才可以操作，否则可能会影响整个项目。

第二个权限，刚刚说了权限完全由系统做分发和转换权限受理和收回。我们做这个事情之前，我们必须要把整个项目的主干权限收回来。很多项目刚开始的时候就被这点难倒了，说主干权限不给我必须要由系统给，万一以后我有什么情况怎么办？这个问题我们也是有办法结果，我们通过最终流程带来的效果，让他们意识到这样做是有好处的。当然最后的检查是更加是一个流程不断优化非常明显的体验。以前我们是必须核完代码，进行公文测试，测试完了以后，开发人员自己确认我合的功能确确实实可以，我们释放权限。后面我们做到由工具自动测试完成以后就可以释放权限。再到后面我们可以确保自动化测试稳定性，确保代码开发合入过程中，有一定的标准、规范的。现在是只要把代码合进去，包能够编出来就能够进去。这样流程不断的演变和优化达到最终效果。

这里也可以看一下这样规则带来效率的提升。我们现在“手Q”那么多的分支，平均合流的时间。这个是指从提交合流申请说我要开始河了，一道最终合流全部结束，系统通过了，这个最快一个半小时，最慢18个小时。可能大家觉得这个数据不够直观化，我们拿一个对比数据。系统上来之前平均一个流合完要需要115个小时。系统上来之后，这个时间缩短到22个小时，现在稳定了，大家比较认同，熟悉度比较高了，现在6个多小时完成合流了。而且这里强调一下，这个6个多小时并不代表整个过程都需要阻塞式的，真正只需要在一小时之内完成合入就可以了。没有完成1小时内的分支做一些追责或者检讨，后面会进一步优化，来分析有什么办法可以继续缩短这个流程。这块优化全部上依赖于这些规则，关键点都在于自动。

我们最后看一下“手Q”这套实现的效果，1.5小时能完成合入，3天内全部完成，我们保证80%的合入是准时的。版本发布的时候95%以上的问题都能够解决，1月到1.5月发布一个版本，这样我们跑了34个版本了。

最后尝试做一下总结，我认为“手Q”在持续集成和持续交付这块，体现的三大要素，正好也是跟所谓敏捷开发或者是DevOps的基本理念，或者说几个比较重要的基本元素是符合的。也就是流程、技术跟组织，首先在流程上我们要制定一个明确的流程，同时这个流程确实是可视性的，而且大家团队共同认同，技术上做到高度自动化，同时通过流程串联来提升整个流程顺畅性，减少人工。