ReaderMX.
持续交付2.0

如何做到行业领先？腾讯会议背后的研发效能改进历程

持持续交付20约 4 分钟

Image

关注我，每天收获一个新技能!

1

引言
腾讯高级管理顾问乔梁说：“一致性是效能提升的必经之路”。
没有规范与标准，散乱的微服务就如同一盘散沙，重复的讨论，重复的操作，重复的问题，消磨团队的耐心与斗志，无法形成合力。

这也是腾讯会议要从标准化建设入手建设研发效能体系的原因。从2020年下半年开始，腾讯会议启动了基础建设与调研，目标是通过半年的专项共建提升团队的整体研发效能。
腾讯会议研发效能体系建设分别从开发域、测试域、部署域、运营域4个方面输出解决方案，对存在的问题逐个击破。
这里有一个非常重大的疑问！！！！

2

为什么没有需求域
有的小伙伴会问：为什么没有需求域？问题从头开始解决，不是更高效么？
这个说法当然没有错，但也应该考虑组织与团队的角色协作关系现状。
“推己及人”，当听到有人说自己的工作速度与质量不达预期时，自己会立即生出“对抗” 情绪。何况，大多数情况下，最终的交付结果并没有直接反映出“在需求域存在问题”，尽管事实上一定会存在一些需要解决的问题。
因此，应该以自我为原点，作为改进的起点。只有当改进过程中遇到具体的问题时，再通过一个个具体的案例来推动其他领域的改进或角色职责边界的清晰与交付质量的提升。

1

开发
遵循乔梁老师提出的“工程一致性”原则，我们选择了两个统一，即：统一编程语言与技术框架 和 CICD部署流水线标准化。
从语言的角度看，没有任何一门语言能“一统天下”，然而，在一定的范围内（比如腾讯会议产品），肯定有一门最适合的语言与框架。我们最终选择公司内部主流的Go语言 + tRPC分别作为开发基础语言和框架。
若统一语言，那么存量的业务模块怎么办？对此，我们采用的策略主要有阻断新增、限时重构，减少支持的力度。
Image
图2 统一语言与框架
1.1.2 统一CI／CD流水线
在研发效能建设前，腾讯会议项目下有一百多种风格的持续集成（CI）流水线。虽然灵活性很高，但也存在节点定义不一致，环境管理不规范，门禁质量标准不统一等问题。当CI／CD流水线在运行过程中出现问题时，问题定位／诊断／修复的成本也很高，开发人员不愿意去管理这些失败，因为很可能自己花了大量的时间，但这些失败与自己的工作无关。
因此统一流水线的建设其实是统一研发流程的起点，因为这是提升代码质量的切入口。
按照研发过程流水线被拆分为5条：
开发流水线→提测流水线→合流流水线→主干流水线→预发布流水线。
当然，为了我们还在以下三个方面进行了改进：（1）提供服务脚手架工具（2）提供性能分析工具（3）“接口即文档”工具。

2

测试域
腾讯会议在测试域的研发效能建设主要三个方面入手：（1）环境治理 （2）快速更新（3）接口测试与压测3方面入手。
2.1 环境治理
环境治理分为环境构建和环境编排两部分。
环境构建：在改进前，腾讯会议测试环境只有一套，而日常并行开发的需求有100多个。所以，环境冲突问题频繁出现，经常阻塞测试进度。“一键快速构建环境”变成腾讯会议必须攻克的难题，环境治理就此诞生。
对测试环境的要求是：由需求而生，也由需求而止。
环境编排：
腾讯会议服务都是基于镜像的模式，因此100多个服务就有100多个镜像，而每个镜像都单独部署，而且腾讯会议的私有化场景也是市场刚需。一套腾讯会议产品的私有化部署，甲方可能只提供2台机器。
腾讯会议的环境编排支持根据自身的需求动态编排模板，快速生成一套环境。在环境中，可以把全量的服务合并到一个镜像，也可以自由编排，把某些服务合并到一个镜像。
Image
2.2 快速更新
快速更新的诉求其实来源于开发层面：如果一个小变更的改动需要5秒钟，而发布需要5分钟，则显然是不能接受的，快速更新就此诞生。
在进行研发效能建设前，采用的是“编译+打包+冷更新”模式；
在进行研发效能建设后，快速更新采用的是“编译+上传+热更新”模式。
更多详细的内容，请参见《如何做到行业领先｜腾讯会议背后的研发效能改进历程》

KEEP THE THREAD GOING

更多来源文章

3700条流水线怎么管？腾讯蓝鲸五年前的特性，恰好适配AI研发

本文以3700条部署流水线的治理困境为切入点，分析UI配置模式在规模化下的短板，阐述Pipeline as Code如何实现配置版本化、校验前置和模板复用，并探讨其作为AI治理地基的适配性。读者将获得规模化配置治理的实战思路与借鉴建议。

阅读全文