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

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，按照业务系统对仓库进行划分，那么会有更一致的迁移过程，迁移时间也会更平滑、更省时。