CODING 代码多仓库实践

关于代码的管理问题已经讨论多年，随着企业业务的复杂度提升、软件行业技术栈的选择度变宽泛，现代软件的代码仓库也变得愈来愈庞大和复杂。一个中型项目，将测试代码、核心业务代码、编译构建、部署打包等基础设施的代码所有加起来，几十万行都是屡见不鲜。而且一个项目每每由多个团队进行协做，如何让多团队在对同一个项目的代码进行协做时不会相互干扰、相互制约，也是每一个企业研发团队在实践中不断摸索的难题。

多仓库与单仓库

对于上文所说的一些问题，业界已经概括了常见的代码仓库存放方式，常见的如单仓库和多仓库。大部分企业会针对不一样的项目采用不一样的仓库管理机制，因此对于企业来讲，常常会两种方式并存：

• 单仓库

将全部项目代码存放在一个代码仓库当中，这个好处在于项目的全部开发者能够共享看到项目中的全部代码；在项目规模较小的时候，一个库能够更好地管理和维护，发版本只要统一发布便可；对于持续集成，也只须要针对一个库维护若干条流水线。但再好的实践以及工具都有它适用的范围。Git 已是很是流行的代码托管工具，但 Git 会把全部历史记录以及代码同步到各个用户的本地机器，因此对于大型项目而言，若是使用单仓库，就意味着某个模块开发者的本地可能有大量冗余代码和提交记录的信息，这个时候拆分红更小的库显得更加合适。

谷歌与 Facebook 就是业界典型的单仓库派表明。做为代码行数已经超过数十亿行、commit 数量累计达到千万次的团队（2015 年的统计数据），若是没有强悍的基础设施，也很难运转顺利。Google 曾发表论文介绍其强大的代码管理系统 Piper 以及客户端工具 CitC，但对于大部分企业来讲是否有必要投入如此之大的研发成本去自研一个代码管理系统值得商榷，因此谷歌的实践对于大部分企业来讲不必定具有参考性。

谷歌代码仓库每周的提交数量

• 多仓库

将项目代码进行必定的拆分放在多个库当中，好处就是将代码进行必定的解耦，对于体型较为庞大的项目来讲管理上会更加清晰和富有弹性。将代码按照必定逻辑分库以后，仓库与模块有了自描述的特征，让一块儿协做的开发者能够一目了然。发布源码版本、持续集成构建时，负责各仓库的研发组织能够按照本身的节奏来发布，同时将一些“坏代码”的影响控制在某个仓库中，而不会影响项目所有代码。分库也有要注意的地方，在同一个项目里的代码多多少少都有业务上或者是技术上的联系，好比编译依赖：以一个Java 项目为例，客户端接口的调用代码到底是直接依赖服务端接口代码的定义，仍是间接依赖？若是是间接依赖，那么分库管理是很是方便的，但同时客户端就没法快速感知到服务端接口定义的变化。因此在进行多仓库划分时，要注意划分的一些经常使用原则。

多仓库在业界使用的很是普遍，在腾讯、华为、阿里的开源项目中咱们都能看到，好比腾讯的 Tars 开源项目（RPC 开发框架）就按照不一样编程语言以及技术栈进行了分库：包括 Java、Go、PHP 等子项目。做为开源项目，一个清晰的分库可让开发者更好地协做，避免没必要要的沟通成本。

Tars 的开源项目子仓库

CODING 的多仓库实践

CODING 在多仓库实践上也遇到过问题。因为前端、后端、git-server 三个模块的代码放置在同一仓库中，以致于代码版本的 tag 须要保持同步，制约了各个团队的开发节奏。每一个模块的进度都得齐头并进，才能保证最终版本是一致的。尽管它们在业务上紧密相连，但实际上这几个模块自己没有编译依赖，因此在没有多仓库功能时，咱们只能创建了三个项目，使用三个项目的代码仓库能力，只集中在一个项目当中进行项目管理工做。

在千呼万唤中，CODING 近期终于正式上线了多仓库功能，咱们的开发人员也终于能够告别傻乎乎地使用一个项目进行管理，又用多个项目进行代码仓库管理的尴尬问题，咱们将那些没有编译依赖的项目，但在业务上又有联系的代码仓库，放置在同一项目的多仓库下，开发人员无需在多个项目中切换。

多仓库功能一直是 CODING 想要投入作的一个特性。随着近几年 CODING 企业用户的快速增加，CODING 的架构也面临着持续的挑战。如何让交付更加顺滑，让特性更快、更好地服务开发者，是咱们进行架构演进的初衷。因此咱们在很早以前就开始了容器化、微服务化的规划与实施，而在微服务化的过程中，包括代码仓库管理在内的研发流程与组织方式也在配套前进着。多仓库这项基本能力就可让多个微服务独立存放在独立的代码仓库当中，配套独立的持续集成流水线，让架构演进变得水道渠成。 咱们知道不少企业用户对多仓库有很大诉求，CODING 的多仓库已正式上线，欢迎你们前去体验。

业界经常使用实践

综上咱们能够看到，代码仓库的组织方式每每和人员组织架构息息相关，并且代码库的拆分也每每和软件架构的演进息息相关。在现代软件架构逐渐由单体朝着分布式、微服务演化时，代码仓库和研发团队的粒度也在逐渐变小，从之前的集中式慢慢变为网状。但不管是单仓库仍是多仓库，最终目的都是为了让开发者更加高效地进行研发。那究竟该如何选择？笔者总结了几条业界的通用实践来供你们思考：

• 技术栈不一样的模块建议多库存放

不一样技术栈的编译环境、构建环境、发布环境每每不一样，代码之间的硬性依赖也不大，能够考虑分库存放。大部分的开发者仍是倾向于在工做中持续使用某一种熟悉的编程语言，因此按照技术栈划分是一个经常使用的实践。

• 仓库的粒度最好和组织架构相匹配

拆库要拆到什么粒度呢？有些研发组织微服务化后，给每一个微服务都分配了一个代码库，随着拆分深刻，一个项目积攒了几百个代码库。但一个 two-pizza 团队每每会负责多个微服务，不只仅是一个。因此建议不要盲目使用大量代码库，避免到后期难以管理，能够考虑按照团队组织来划分代码仓库。

• 拆库并不意味着创建部门墙

很多企业代码拆分以后可能顺便就把团队之间的代码权限也作了划分，建议研发团队慎重考虑。关闭了代码权限就意味着，团队与团队之间再也不互相 review 代码，相应的工做上的交流也会逐渐减小。若是读者的企业属于内部开放型氛围的公司，或者想要成为开放型的公司，那么关于此点请三思。

reference：
https://cacm.acm.org/magazine...

点击当即体验 CODING 多仓库功能