腾讯把需求和代码统一的内幕
DevOps是很全面的概念，站在某一角度或少只能代表一部分看法。特别在大型企业，不同团队有不同的职责，决定了各自会关注不同的方向。
本次会场可以说是DOIS主办方的一次突破性尝试，三位讲师来自腾讯的不同部门，日常工作也是各司其职。我们通过一个上午的分享，从研发过程链条的前中后三个不同的视角来分享对DevOps的解读和看法。
本文是DOIS大会腾讯专场研发管理方面的分享内容。
笔者来自腾讯技术工程事业群研发管理部，该部门提供的服务支撑了全腾讯业务，本次分享聚焦于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中出现了分支权限，能否解释一下？
因为需要考虑大型项目的日常管理，很多项目组有至少几十人的团队，之后又拆分成几个小团队，在分支策略上，往往不同团队要管理不同分支。此时，库级别的权限能力就不够用了，必须在分支上增加权限控制。这也是工蜂的一项特有功能，后续会进一步优化。
展会花絮
