腾讯DevOps与研发管理的实践
Posted 研发创新
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了腾讯DevOps与研发管理的实践相关的知识，希望对你有一定的参考价值。
在5月5日的DevOpsDays Beijing，CODE平台产品经理marssun分享介绍了腾讯研发工具体系，并通过两个研发过程中的实践案例说明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的腾讯账号下搜索到。
腾讯研发工具链上开源过的工具和组件：
| 1 | bk_cmdb（蓝鲸） |
| 2 | Tars |
| 3 | GAutomator（WeTest） |
| 4 | QTA |
| 5 | TscanCode |
| 6 | GT |
| 7 | OOMDetector |
本文介绍几个冷门项目：
看截图很快能知道是互娱的项目，这个项目是个Unity的自动化测试框架，它是WeTest的其中一个模块，WeTest是个真机测试云的解决方案，用成千上万台不同型号的手机跑各个机型的自动化测试。
同样是来自互娱的TScanCode，做的是静态代码扫描，支持C++和Lua，帮你分析代码中的潜在漏洞。
QTA是SNG社交网络质量部出品的自动化测试框架，承担了SNG多数业务包括腾讯云的部分业务在内的自动化测试需求。支持移动APP、Windows程序、网页、服务端、接口多种不同平台的测试任务，开源的部分放出了android和ios的测试库插件，分别是QT4A和QT4i，其中QTAF是其核心框架的核心模块。有兴趣交流可以在Github的项目上给项目组提issue。
本文通过分享几个研发过程优化的例子，说明了DevOps端到端的思想不仅仅是针对运维的，它还对研发管理，特别是质量控制很有价值，并且能够直接改善研发团队的体验，减少沟通损耗，提高研发效率。同时也介绍了腾讯内部的实现经验。在流程改进上还有很多的路径或者体验可以优化，希望与同行共勉。
以上是关于腾讯DevOps与研发管理的实践的主要内容，如果未能解决你的问题，请参考以下文章
CODING DevOps 高可用实践，保障服务稳定的“定海神针”
CODING DevOps 高可用实践，保障服务稳定的“定海神针”