腾讯把需求和代码统一的内幕

笔者来自腾讯技术工程事业群研发管理部,该部门提供的服务支撑了全腾讯业务,本次分享聚焦于DevOps中的敏捷研发和配置管理。很多朋友问起说腾讯这么大的公司,那么内部的研发是怎样做的,研发效率是怎样保证的? 

我们在以前的分享也提到过,腾讯有种类繁多的广泛的产品线,产品数量多。下图列出了一部分,更多的产品是没能列上的。 

在这些产品背后是腾讯15,000~16,000名技术人员,这里包括的不只是开发,也包含测试和运维。而产品员工大约是6000左右,包含了所有的产品经理、运营、游戏策划和项目经理。合计总人数大约22,000左右。 

从研发效率来说,单位人员所提供的产品能力,体现了整个集团的人均研发效率。腾讯用数量并不太多的员工人数,维持了如此多款不同产品,我把其中研发效率的关键因素归结为4点: 

1.雇佣杰出的研发和产品人员 

2.由下而上自组织的敏捷 

3.自动化的研发工具体系 

4.科学高效的质量控制能力 

今天的分享着重来看第二点,也就是“敏捷”对于腾讯集团这样的大型企业代表着什么。 

研发的现状

研发过程中主要有两种角色,分别是产品和研发。产品经理把需求排进需求池,和研发勾兑好,经过线上线下若干轮pk,划分优先级排进迭代,研发团队经过内部沟通,做好架构设计,然后把需求拆分给不同的人来实现,也就是任务分配。之后,开发开始写代码,写代码的过程中又需要各种各样的沟通,比如有些依赖或者技术接口,再比如产品需求发现有些之前没想到的疑问回去勾兑。等到功能大致开发好,测试开始介入,这个时候产品、开发和测试坐在一起,又要核对测试的需求,在测试过程当中还要勾兑开发环境。最后,在测试当中发现的问题,又要和产品和研发一起识别和跟踪。 

再进一步,从迭代规划开始,研发团队先要对根据产品节奏,对自己的版本做规划。当然不同形态的产品,规划出的结果是大相径庭的,如果是互联网产品,那么规划往往与发布节奏有关,如果是交付给用户的产品,比如说腾讯云TCE和TSTACK,这些产品要对不同的客户有不同定制,版本规划肯定又会和客户交付有关。在有版本规划之后,研发leader开始分活儿,那么分得任务又开始与分支规划有关,是要主干开发呢?还是要特性分支开发呢?还是要一个人一个分支开发能?那么怎么规划?此时研发Leader有责任规范研发团队的作为,我们要改分支开发模式呢还是如何?之后提交、到合流、到缺陷反馈时候的自动化检测,最后再到发布交付都要怎麽做?仔细想想看,每个团队在跑熟流程前,还有遇到问题解决问题的时候都要经过大量的沟通。这些沟通只能在产品团队、研发团队、质量团队和CMO(也就是配置管理员)中内部消化。 

(现代研发复杂的控制节点) 

回想一下整个过程,即便没有讲细,也讲了如此之多的步骤。却还没谈怎么写代码,反而把时间在规范、交流、沟通中浪费掉了。 

回顾下互联网时代早期,需求、迭代、IPM、Scrum、缺陷反馈等等这些概念,其实并不流行。例如腾讯在Pony、Tony还写代码的时代,写第一版QQ时,也未必真的了解IPM是什么。举一反三,在一个行业发展的初期,往往是研发效率最高的时刻。例如前两年的AI围棋,团队可以只有很少的人就能实现突破性进展,可以说:越在行业初期,研发团队越简单幸福。 

但是时代决定了大家不能一直这么开心的走下去,因为软件工程越来越复杂,版本越来越多,功能越来越强大,注定了研发团队不可能一直是个小规模的组织。组织越大,个体之间的隔阂就越大,隔阂直接带来的就是沟通成本的增加。 

沟通是敏捷和DevOps的共性本质

Agile也好,极限编程也好,Scrum也好,这些“敏捷”实践都是一种沟通的规范或者方法论。他们本质上解决的问题都是沟通上的问题——你不懂我,我不懂你,我要懂你,就要紧密的在一起。 

可以说沟通效率的优化,是敏捷运动和DevOps运动的一个共性本质。DevOps说的什么?研发和运维紧密的在一起。 

敏捷方法论中,规范的是人与人之间的沟通。DevOps则更进一步,涵盖了人与机器的沟通以及机器与机器的沟通。 

DevOps进一步实现了人机的自动化对接。 

在DevOps提供的全链路数字化链接的基础上,下一步发展会是什么?发人深省,细思极恐 

那么从集团层面想要提升效率,要在各种场景下优化沟通。怎么样优化沟通呢?在这方面腾讯做到了三件事: 

腾讯在优化沟通上所做的三件事 

第一点是在组织上减少职务鸿沟

本文不讲企业管理,略过 

第二点是信息化

这里笔者放了几张对比图: 

上例虽然用图有些夸张,主要是为了阐明观点便于理解:如果能用TAPD写的干嘛要去写纸条,写完了还得粘,粘完了还得撕,是一件累人的事。技术文档亦然,能用文本格式化在代码库里,为什么要写doc? 

敏捷从诞生开始到现在,Scrum已经有20多年的历史。如此漫长的时间段中,Scrum从理论层面上看几乎没有什么变化。 

但这20多年间,世界已经前行,特别是人们的沟通方式发生了巨变。从口口相传,到有电话,到PC,到Internet,到移动网络,到智能设备,到微信等等,沟通的工具一直在升级换代。 

代码库在公有云的外网虽然现在还没和企业微信集成,但腾讯内的版本很早就实现了IM通知,比如在家休假,完全靠手机就可以了解到我们团队的编码进度,分支合并的消息都直接通过企业微信push到手机上,周末也都知道谁在加班。同样对于TAPD,如果需求有变化,可以通过手机上企业微信直接查看。 

在信息化上,新的概念是办公无边界,包含办公桌上的PC,家的PC,移动终端和智能设备,使用统一的鉴权和认证方案,实现研发过程中信息的无界传达。 

第三点,确定统一的沟通体验

腾讯在统一沟通体验上非常有原则,我们知道腾讯有非常多不同形态的业务,导致在研发工具链上有很多不同的工具和体系。 

但是,却保障了最基本的沟通工具是统一的。 

研发管理部负责了两大研发平台,TAPD是腾讯的敏捷研发平台,承载了全公司的产品规划、迭代、测试计划、任务分配等等;Code是腾讯的源码管理平台,现在是工蜂,负责了全腾讯的代码库、资源文件、分支、审查、合并发布到内部开源的研发链路。 

所以即便腾讯如此讲究内部赛马,但最基础沟通工具的统一还是没丢。 

保持高频沟通应用的统一具有两大好处,首先,它给集团内的业务合作减少了障碍,当两个平时业务互不相关的部门相互合作时,因为系统和账号相通,只需要加入对应的权限就行了;其次,统一沟通应用为集团内的人员流动创造了便利,一旦人员转岗,在集团内统一的沟通体验让调动人可以快速适应工作。 

DevOps系统的桥接形式

接下来看看DevOps在系统之间是怎样互相桥接的。DevOps关注的两块过程改进,一个是研发的过程,一个是质量的过程。严格意义来说研发闭环是可以包含多个质量过程闭环的。那么在这两个流程的闭环中,都会涉及到若干种不同的工具。 

特别在一些领域,一款工具很难满足全部的需要。比如说移动项目用jenkins,游戏也用就不太好,再比如说小型机,很难找到开源的CI工具做编译。这就导致不同的业务形态会有不同的工具。为了让整个系统流转起来,工具和工具之间的相互调用,对于腾讯来说,最好的方式是通过松耦合。 

松耦合的概念是支持但不依赖。系统和系统之间都通过通用的接口和Hooks互相调用。同时腾讯内网的研发系统,已经逐步使用OAuth代替传统token验证,来保证访问的多方安全性。 

先来看内置集成的例子,也就是平台产品直接提供的功能,这里举的是TAPD中关联工蜂的代码仓库。 

第一步,TAPD的项目设置页面,点关联Git项目 

第二步,认证TAPD的授权到工蜂,这里是一个OAuthV2的授权框 

第三步,选择你要绑定的git项目,点确定完成 

当push时,在评论带上–tapdid这样一个参数,就能把对应的提交点绑定到需求上。 

只需三步,需求关联你的代码库。 

但是理想是丰满的,现实是骨干的。产品这样设计的功能,并不是所有的用户都买单,团队往往需要根据自己的特性来定制流程。下面用微信安卓团队例子看看开发团队怎么做。 

整个团队每月大概处理 300 ~ 500 个需求,平均每个人做10个,采用特性分支的协作模型项目,每月一个迭代,3到4个Feature Team并行开发。 

这个是微信的使用的分支模型,可以看到它是一个典型的特性分支发布模型。根据每个月的发布节奏设置了关键分支。 

先来看他们怎么把需求和代码关联起来的,他们并不满足于单纯把需求和提交绑定,而是做了全方位的关联: 

项目的默认分支就是代表当前迭代,历史发布的版本、当前版本和计划开发的未来版本,都对应每个月的保护分支和发布TAG。每个需求则对应一个或多个Feature分支。 

这是微信项目在TAPD一个迭代的需求页面 

这是合并请求页面,他们要求开发自己把需求单粘进合并请求单里: 

如果格式不对,或者需求不存在,就自动提示你需要填写正确的需求单。 

同时如果产品经理说需求这个月还不能发布,也能通过tapd的标识,来直接拦截合并请求单。 

同样和代码库集成的还有自动化扫描和测试流程,流程就不仔细说了,也是通过松耦合的方式来实现自动化调用。当扫描检测失败的时候自动阻拦合并请求,从代码级别上拦截特性分支的合入。 

(自动化质量检测接口调用模型)腾讯企业级研发平台的要求

一个成熟的企业级研发系统,以代码管理为例,至少要在这4个方面能达到基本要求: 

存储对腾讯来说,总容量必须无限大,单库容量必须能支撑大型图游这样级别的项目。 

在管理层面,人员、权限、和项目必须做到企业可控,这一点也是硬性条件。 

在网络层面,腾讯因为有多个办公地,其中还有海外的,想要访问项目足够快就要在邻近节点部署环境,来节省专线的带宽,那么系统的多地就近访问,在腾讯来说也是一个必备功能。 

在安全方面更是硬性要求,不能因为一个员工今天和领导闹矛盾就删库跑路数据就找不回来了,同时,业务系统也要满足企业内各种各样的合规和审查要求,比如查一下上个月某个项目组的访问记录。 

腾讯工蜂正是在这些要求下给腾讯量身定做的系统,目前已经服务了包括微信在内数不清的腾讯业务。 

在系统设计上,也考虑了行业先进的思想和经验。系统直接集成了代码检视能力,支持高数量级的分支管理,支持会话式开发,在工作过程中的动向通过动态的模式展示,同时集成和定制能力是全方位的,每一个可以操作的功能基本都有它对应的API或Hooks。 

在企业管理方面也做了多层加强 

会后答问

问:腾讯为什么选择Git作为下一代代码管理平台?

腾讯大约在2015~2016年意识到上一代SCM的不足,在2015~2017年间,阿里、百度、微软等公司已经全面切换Git,新一代的Git系统并非单纯的Git,而是一套高度集成化,承载多项能力的效能平台。新一代思想设计下的系统在使用过程中,潜移默化的大幅增加研发过程中的沟通效率,并能够将研发过程沉淀下来。 

问:如何看待Git和传统SCM在权限组织上的差异?

Git在团队实践过程中,巧妙的培养的业务团队拆分架构和组件的行为。帮助项目架构更合理的结构化拆分,这种划分大项目为细粒度的行为反而有助于权限的分散管理。这是经过实践所得出的结论。 

问:看到ppt中出现了分支权限,能否解释一下?

因为需要考虑大型项目的日常管理,很多项目组有至少几十人的团队,之后又拆分成几个小团队,在分支策略上,往往不同团队要管理不同分支。此时,库级别的权限能力就不够用了,必须在分支上增加权限控制。这也是工蜂的一项特有功能,后续会进一步优化。

转自:开发者头条

来源:软件工程之思,本文观点不代表自营销立场,网址:https://www.zyxiao.com/p/109382

发表评论

登录后才能评论
服务中心
服务中心
联系客服
联系客服
侵权联系 投诉举报
返回顶部
河南,挺住!郑州,挺住!一起为他们加油!!