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
複製代碼

不過淺克隆限制較多，通常用於對遠程版本庫的查看和研究。

不能從淺克隆版本庫克隆出新的版本庫。
其餘版本庫不能從淺克隆獲取提交。
其餘版本庫不能推送提交到淺克隆版本庫。
不要從淺克隆版本庫推送提交至其餘版本庫，除非確認推送的目標版本庫包含淺克隆版本庫中缺失的所有歷史提交，不然會形成目標版本庫包含不完整的提交歷史致使版本庫沒法操做。
在淺克隆版本庫中執行合併操做時，若是所合併的提交出如今淺克隆歷史中，則能夠順利合併，不然會出現大量的衝突，就好像和無關的歷史進行合併同樣。