CODING 代码多仓库实践
关于代码的管理问题已经讨论多年，随着企业业务的复杂度提高、软件行业技术栈的选择度变宽泛，现代软件的代码仓库也变得越来越庞大和复杂。一个中型项目，将测试代码、核心业务代码、编译构建、部署打包等基础设施的代码全部加起来，几十万行都是家常便饭。并且一个项目往往由多个团队进行协作，如何让多团队在对同一个项目的代码进行协作时不会相互干扰、相互制约，也是每个企业研发团队在实践中不断摸索的难题。
多仓库与单仓库
对于上文所说的一些问题，业界已经归纳了常见的代码仓库存放方式，常见的如单仓库和多仓库。大部分企业会针对不同的项目采用不同的仓库管理机制，所以对于企业来说，经常会两种方式并存：
- 单仓库
将所有项目代码存放在一个代码仓库当中，这个好处在于项目的所有开发者可以共享看到项目中的所有代码；在项目规模较小的时候，一个库可以更好地管理和维护，发版本只要统一发布即可；对于持续集成，也只需要针对一个库维护若干条流水线。但再好的实践以及工具都有它适用的范围。Git 已经是非常流行的代码托管工具，但 Git 会把所有历史记录以及代码同步到各个用户的本地机器，所以对于大型项目而言，如果使用单仓库，就意味着某个模块开发者的本地可能有大量冗余代码和提交记录的信息，这个时候拆分成更小的库显得更加合适。
谷歌与 Facebook 就是业界典型的单仓库派代表。作为代码行数已经超过数十亿行、commit 数量累计达到千万次的团队（2015 年的统计数据），如果没有强悍的基础设施，也很难运转顺利。Google 曾发表论文介绍其强大的代码管理系统 Piper 以及客户端工具 CitC，但对于大部分企业来说是否有必要投入如此之大的研发成本去自研一个代码管理系统值得商榷，所以谷歌的实践对于大部分企业来说不一定具备参考性。
多仓库功能一直是 CODING 想要投入做的一个特性。随着近几年 CODING 企业用户的快速增长，CODING 的架构也面临着持续的挑战。如何让交付更加顺滑，让特性更快、更好地服务开发者，是我们进行架构演进的初衷。所以我们在很早之前就开始了容器化、微服务化的规划与实施，而在微服务化的过程当中，包括代码仓库管理在内的研发流程与组织方式也在配套前进着。多仓库这项基本能力就可以让多个微服务独立存放在独立的代码仓库当中，配套独立的持续集成流水线，让架构演进变得水道渠成。 我们知道很多企业用户对多仓库有很大诉求，CODING 的多仓库已正式上线，欢迎大家前去体验。
业界常用实践
综上我们可以看到，代码仓库的组织方式往往和人员组织架构息息相关，而且代码库的拆分也往往和软件架构的演进息息相关。在现代软件架构逐渐由单体朝着分布式、微服务演化时，代码仓库和研发团队的粒度也在逐渐变小，从以前的集中式慢慢变为网状。但无论是单仓库还是多仓库，最终目的都是为了让开发者更加高效地进行研发。那究竟该如何选择？笔者总结了几条业界的通用实践来供大家思考：
- 技术栈不同的模块建议多库存放
不同技术栈的编译环境、构建环境、发布环境往往不同，代码之间的硬性依赖也不大，可以考虑分库存放。大部分的开发者还是倾向于在工作中持续使用某一种熟悉的编程语言，所以按照技术栈划分是一个常用的实践。
- 仓库的粒度最好和组织架构相匹配
拆库要拆到什么粒度呢？有些研发组织微服务化后，给每个微服务都分配了一个代码库，随着拆分深入，一个项目积攒了几百个代码库。但一个 two-pizza 团队往往会负责多个微服务，不仅仅是一个。所以建议不要盲目使用大量代码库，避免到后期难以管理，可以考虑按照团队组织来划分代码仓库。
- 拆库并不意味着建立部门墙
不少企业代码拆分之后可能顺便就把团队之间的代码权限也做了划分，建议研发团队慎重考虑。关闭了代码权限就意味着，团队与团队之间不再互相 review 代码，相应的工作上的交流也会逐渐减少。如果读者的企业属于内部开放型氛围的公司，或者想要成为开放型的公司，那么关于此点请三思。
reference：
