我们的系统是一个假的微服务架构,虽然有很多微服务组件,但实际需要把所有微服务都打包到一起来安装和部署。
个中缘由就不展开了。现在领导提出新的要求,要把单体仓库拆分成每个组件独立的仓库,来实现对代码权限的细分。
但这种 multi repo 的形式对 CI 构建打包造成了很大的挑战:由于我们的微服务架构是假微服务,实际上某些组件之间是有强依赖的,当某个新特性开发时,相关组件都需要一起刷版本,才能实现正确的功能,否则会因为接口对不上之类的情况而不能正常工作。
由于 gitlab 的 CI 对于跨库的 pipeline 支持较弱,只能通过 trigger 下游的方式来创建关联性;这在 multi repo 数量越来越多的情况下是灾难性的。
所以我们想为 CI 创建一个 MonoRepo ,由权限较高的用户来控制,它可以以 submodule 的方式把所有子仓库都收集到一起,然后在这个仓库中定义 CI Pipeline 就比较清晰。
各微服务组件有自己独立的仓库,可以在上面自由开发,每周或每个特性再提一笔 MR 到 MonoRepo 来,使主仓库集成该改动。基于 MR 可以触发整个系统的打包,供测试取用。
submodule 方式也有它的弊端——子仓库的一项变动,提交到主仓库时,仅仅表现为一个 commit id 的变化。这中间如果有操作失误,或者别的错误合入,主仓库的管理者是不容易察觉的。
所以我们想用 git subtree 的方式来建立这个主仓库,在这个形式下,每个子库的代码会直接以实体文件存在于主仓库中,改动提过来也会是代码形式的改动。
已知的缺点就是,主仓库只有高权限用户可见,所以变更提交也得由高权限用户发起,相当于领导自己提 MR 自己审。(但这个缺点在 submodule 方案中也存在,我们可以为它调整研发流程,例如用 bot 自动创建)
如果有多项任务并行在开发,容易发生冲突吗? (因为我们察觉到 subtree 合并时发生的冲突解决起来比较麻烦,如果在主仓库解决了,主仓库代码就跟子仓库脱节了,所以得回子仓库去解决)
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.