全国协议5人面授小班,企业级独立开发考核,转业者的IT软件工程师基地 登录/注册 | 如何报名

免费领取试听课程

并获得专业顾问一对一进行选课辅导

课程名称不能为空
姓名不能为空
手机号码不能为空

领取成功

通过微信后端仓库发展了解单多仓

行业新闻 汉码未来 | 微信 后端 单仓 多仓

2021-09-29 14:34:35

微信后台代码存储的历史很早就开始了,今天我们就一步一步地介绍了微信后台是如何构建一套真正可行的小仓方案,并将这样一种仓位分享出来 。

通过微信后端仓库发展了解单多仓

1微信后台代码仓库的发展历程。

熟悉微信后端开发的人都知道,微信项目启动是一种很偶然的尝试,微信最初来自广州研发部的一个创意,微信后端就继承了QQ邮箱。如果对代码进行了仔细的分析,你将发现在许多部署的路径中使用QQMail等hardcode(当然,现在不建议这么做)。在此,我们首先回顾一下代码仓库的发展历程。


山东济南汉码未来了解到,微信当初大部分代码都是从QQ邮箱原封不动的复制,只是创建了一个新的svn仓库来编写业务代码。然而,由于业务的快速发展,代码管理中出现了一些不和谐的音符。

一开始大家只把代码仓库当成放东西的地方,甚至有些正式数据放在仓库上;

随后,公共平台项目爆发,一些不属于微信基础后端的代码(如公共平台的代码)也被放置在这个仓库下,但新的微信基础团队不应该有权看到公共平台的代码;

由于代码存储在基于SVN的大仓库模式中,核心仓库的代码权限审批特别复杂。只有少数人有通用公共组件和通用后端框架的权限,这使得理想的新人很难为基础库贡献代码。无奈之下,一些业务的公共库只能放在业务代码下,这些公共函数最终被吸收到公共组件文件夹中,使代码重复;

新人不想分享代码,而且厌倦了各种流程的审批,代码仓库权限的争吵,最终这些流程消除了他们的热情,同时他不自己的业务不能上线,所以只能找到自己有权限放代码的地方,最终导致代码结构的混乱,这是大仓库很难解决的问题。大仓库的权限控制是集中的。在集中文件夹审批过程中,理想的开发者拒绝让宝贵的时间和权限审批人员互相争论;

代码重复的根本原因不是随意放置的第三方仓库,而是散落在商业代码仓库的各种公共逻辑的私有化。

因为没有统一的系统构建,改变微服务的基本流程是野蛮的。

在本机调试代码后上传到svn;

在专用编译器上更新svn;

用魔改版的blade编译release版本的二进制;

如果要发送配置,前端页面模板需要手动将文本文件scp发送到编译器上(当然也可以直接将开发版本的二进制scp发送到编译器上,省去1,2,3);

向微信运维门户提交发布单,告诉发布系统需要更新哪些文件,需要重启哪些服务;

将微信运维门户发布到预发布环境;

灰度→全线。

单元测试全靠自觉,上线前不会跑cc_test,不写单元测试也没关系,就是这么野蛮。

在bazel中切换整个WXG后端编译系统是一项收益巨大但困难的工作。但是WXG的代码仓库距离很远,在2017年代,WXG仍然使用SVN的多仓式模式,这导致了在切换构建工具时需要迁移整个仓库。当迁移的工程师提供了blade2bazel的转换工具和一系列移植方案时,您完全不知道迁移工具是否具有BUG,这时,您已经为所有WXG后端开发提供了转换工具。

更新后端构建工具魔改版的blade,继续魔改,如果BUILD_OF_BLADE将使用这个文件,否则仍然是使用BUILD;

提供blade2bazel工具,试着把blade版本BUILD转换成bazel版的BUILD,备份原来的文件是BUILD_OF_BLADE;

在日常构建中发现bazel的BUILD文件或者不能转换文件,提示开发根据指南进行修改;

一段时间内,开发要求持续维护BUILD和BUILD_OF_BLADE的构建脚本;

根据repo移植构建工具。在所有repo完成迁移之前,取消blade。

那时,所有的开发都坚持“技术升级不会阻碍企业发展”的理念,而WXG中最重要的思想是灰色,平滑升级,无商业意识(这一想法也适用于高效能团队)。

而且那时微信后台都启用了分仓模式,使这个过程不那么艰难。

可先取小仓库进行试点,收集反馈,打磨方案;

工具链仓库可以用不同的分支进行开发,小范围试点时,在构建系统中对编译账户合理配置仓库,可以使不同仓库构建系统的升级切换平滑;

在试点一个时期方案成熟后,只需调整与编译帐号对应的构建工具库的分支,就可以将新的构建工具应用到其他仓库中;

整体调节在阵痛期均可回退,而库房很小,足以保证灰度和回退粒度。当然,一些大仓的支持者可能会质疑大仓分文件夹也能做到这一点。虽然signatefolder也可以这样做,但是您会让每个依赖联创建一个分支么。或者就像有些好战分子一头扎进去,一次完全更换整个构建系统,一旦发生构建失败,堵塞的是每天上千个微信后台发布流程,这显然是不能接受的。

那时候切换bazel还有一个有趣的故事。之前由于mmtenpay仓库太大,一直没有进行任何处理,即使有升级工具的加持,仍然成为日常构建中的瓶颈瓶颈。还有一部分是更开放的开发,一个mmtenpay_bazel的仓库就可以单独使用bazel作为构建工具。想象一下,在那个时候,如果有一个整洁的GIT,按照业务系统对仓库进行划分,那么会有更一致的迁移过程,迁移时间也会更平滑、更省时。




以上就是汉码未来给大家分享的文章,希望对小伙伴们有所帮助,想要了解更多通过微信后端仓库发展了解单多仓相关内容的小伙伴可以登录汉码未来官网咨询,主打5人小班,全程面授,主打Java开发,web前端开发等课程,有专业的授课老师为你答疑解惑。

    

分享到:



【免责声明】由于政策等各方面情况的不断调整与变化,本网站所提供的信息仅供参考,请以权威部门公布的正式信息为准。本网站在文章内容来源出处标注为其他平台的稿件均为转载稿,免费转载出于非商业性学习目的,版权归原作者所有。如您对内容、版权等问题存在异议请与本站联系,我们会及时进行处理解决。 删除,请联系客服。
为什么选择汉码未来