monorepo仓库管理方式探秘

时间 2020-01-01

标签 monorepo 仓库管理方式探秘繁體版

原文原文链接

前言

随着功能和业务量级的飙升，前端代码量级也愈来愈大，管理运维的成本也进一步增长。
代码仓库的运营管理挑战也浮出水面。
主流方案有两种：一是multirepo式的分散式的独立仓库，二是monorepo式的集中管理，各有千秋，下面就结合实际场景一块儿深刻了解下。html

分散式管理：multirepo

即按照功能或者其余维度，将项目拆分为不一样模块单独维护于各自仓库中。前端

使用场景

对于敏捷迭代快速开发的新需求，常规作法就是每一个模块对应一个仓库，新的需求进行归类，可纳入已有仓库则进行迭代，不知足则新建仓库。git

优点

1.灵活

不一样模块独立维护，与其余模块自然隔离。各个模块能够选择适合本身的风格、工具等。程序员

2.安全

得益于模块的拆分，权限控制较为天然。
开发时只关注相关部分，不会误操做其余内容。发布上线，对其余模块无感知。github

问题

做为传统的管理组织方式，发展演进这么久，必然会存在一些限制。突出体如今协做和管理成本上。npm

1. 管理成本

常见的项目交接时，每一个人都负责了一堆项目、帐号等，只能手动梳理，还存在漏掉的可能。我当初经历过几回大的调整，交接的真是一脸懵逼和心痛。来个需求才发现还有个仓库一直处于遗忘的角落。安全

2. 协做成本

涉及多个项目开发时，本地开发须要打开多个IDE在其中切换。
对于本地调试等也是个繁琐的过程，虽然存在npm link等方式。bash

3. 依赖升级

这种场景通常出如今依赖的核心模块上，特别是自行开发的基础依赖，不得不升级时简直一言难尽，数目直逼上百的项目，每一个都要修改发布一次。babel

上面说的是业务模块，对于开源或者公司内部基础性工具，升级这里的问题更显著一些。对于程序员俩说，出现问题解决问题就是，所以集中式的管理模式就出现了。运维

集中式管理：monorepo

monorepo 的核心观点是全部的项目在一个代码仓库中。严格的统一和收归，以利于统一的升级和管理。不过这并非说代码没有组织的随意存放。相反，在文件目录上体现出管理结构的要求更高，不然可维护性更低。例如Babel，每一个模块都在指定的packages目录下。

优点

既然是基于问题的演进，其实优点比较明显，就是multirepo的局限的解决。例如协做、运营管理等成本下降。
不过monorepo也不全是益处，相反其局限也比较明显。

问题

1. 项目体积增长

随着项目的发展，体积会逐渐增大，甚至成为巨无霸项目体积几个G。天然带来一些问题：

获取时间变长

拿babel举个例子，虽然只有130M，但时间已经增长很多，更遑论上G的存在。 xxdy.tech/img/mono.gi…[动图太大，始终上传不成功，只能放个连接了。。。]
编译耗时增长
很天然，若是每次仍是所有编译的话，开发、部署时的等待时间会至关的长

2. 安全性

所有功能就这样暴露在全部开发者面前，安全性是个大问题。
误操做的可能性，若是仅仅寄但愿于开发者素质和codereview时的人工复检是不可靠的。

解决方案

固然对于比较成熟的模式，解决方案也是造成了沉淀的。

1. 多模块管理工具

针对复杂的项目模块，天然须要有贴合实际的管理工具。
例如lerna，自我定位就是:
A tool for managing JavaScript projects with multiple packages 至于详细用法，你们能够经过官网查看。

2. git稀疏检出

针对开发者只关注相应内容的解决方案能够依托git来实现的。 Git在1.7版本后，已经支持只Checkout部份内容，即稀疏检出(sparse checkout)

稀疏检出就是本地版本库检出时不检出所有，只将指定的文件从本地版本库检出到工做区，而其余未指定的文件则不予检出（即便这些文件存在于工做区，其修改也会被忽略）。

也就是咱们能够在工做区只关注相关的模块，虽然文件所有pull了下来，但展现和管理式会忽略其余文件，即便展现了其余文件并进行了修改，修改依然会被忽略。例如babel中咱们只展现 babel-cli 内容部分，操做以下：

// 建立文件夹
mkdir demo && cd demo
// 初始化git 
git init
git remote add origin https://github.com/babel/babel.git
// 打开 开关 
git config core.sparsecheckout true
// 指定目录
echo "packages/babel-cli/" >> .git/info/sparse-checkout
// 获取代码
git pull origin master
复制代码

这样，咱们ls能够查看到文件内容只有：

packages/babel-cli
复制代码

若是须要修改展现目录，直接修改.git/info/sparse-checkout，便可，而后从新进行checkout

echo "packages/babel-cli/" >> .git/info/sparse-checkout
git checkout master
复制代码

这样增长了安全性。

扩展：浅克隆

稀疏检出只是展现上的部分，自己仍然包含全部的文件和历史。若是只关注最近的提交，能够经过浅克隆实现。使用：

git clone --depth 2 https://github.com/babel/babel.git
复制代码

不过浅克隆限制较多，通常用于对远程版本库的查看和研究。

不能从浅克隆版本库克隆出新的版本库。
其余版本库不能从浅克隆获取提交。
其余版本库不能推送提交到浅克隆版本库。
不要从浅克隆版本库推送提交至其余版本库，除非确认推送的目标版本库包含浅克隆版本库中缺失的所有历史提交，不然会形成目标版本库包含不完整的提交历史致使版本库没法操做。
在浅克隆版本库中执行合并操做时，若是所合并的提交出如今浅克隆历史中，则能够顺利合并，不然会出现大量的冲突，就好像和无关的历史进行合并同样。

结束语

本文简单介绍了不一样的仓库管理模式理念和一些实践方式，我的理解有限，抛砖引玉，欢迎一块儿讨论。更多内容请转雨打梨梦三村边。