一、困境頻生 前端代碼管理何解？

前端代碼管理一直是困擾不少前端開發團隊的難題，從開發到發布的整體作業流程中，除了常規的技術問題外，往往還伴隨著溝通成本、維護成本及協作效率等問題，這些問題在團隊規模較小的時候可能不太明顯，但是當團隊規模變大時就矛盾越發凸顯，

數堆疊前端開發團隊負責著離線開發，實時開發，資料服務等多條產品線的開發和維護作業，面對眾多的產品線，如何合理的管理代碼，成了團隊需要思考的問題，雖然借助了Multirepo進行管理，但還是遇到了許多難題：

● 私有源維護成本增加

為復用相關業務邏輯，團隊內部抽象出一些私有包，由于不能在公網暴露，為了管理這些私有包團隊使用了私有源，但由于搭建私有源服務器資源問題，私有源常常不穩定且下載速度慢，特別是對于需要原始碼交付的某些客戶來說，安裝這些私有包更會遇到各種問題，交付的時間和人力成本大大升高，

● 邏輯難復用，重復造輪子

各個倉庫中會抽象出同一功能的組件，組件之間的共享往往難以同步，造成了「重復造輪子」等現象，

● 工具/配置不統一，溝通成本高

各個倉庫所使用的工具和配置沒有進行統一，在進行配置更新等的程序中，往往需要同步到各個產品線負責人，溝通成本較高，

這些問題嚴重拖慢了數堆疊前端團隊從開發到發布的整體流程，同時增加了團隊的維護成本和溝通成本，如何尋找新的工具解決這些問題已迫在眉睫，在進行了深入調研和多次討論的程序中，新的專案管理方式Monorepo 在這時映入了我們的眼簾，

二、MultirepoVSMonorepo

那么Multirepo和Monorepo到底是什么呢？其實他們分別代表的是兩種前端代碼管理方式：

Multirepo

Multirepo是一種分散式的前端代碼管理方式，按照功能或其他維度，將專案拆分為不同模塊并單獨維護于各自倉庫中，作為傳統的管理方式，Multirepo具備靈活度高、安全控制等特點，但同時也帶了管理成本和寫作成本的增加，依賴升級等問題，

Monorepo

Monorepo是集中式管理的前端代碼管理方式，將所有的專案在集中一個代碼倉庫中進行管理，嚴格的統一和收歸，有利于統一的升級和管理，作為新型的管理方式，Monorepo有效降低了運營及協作成本，但一個代碼倉庫的管理模式帶來了專案體積的上升，獲取時間延長，同時安全性也有所下降，

上圖為Multirepo和Monorepo對比圖，從圖中我們可以簡要歸納：

• Multirepo是由多個倉庫組成的專案管理方式，每個倉庫有著獨立的作業流、組件與配置

• Monorepo則將不同倉庫整合成為一個倉庫，并共享作業流、組件與配置，

兩種管理方式各有千秋，不能簡單的定義哪種方式更好，但Monorepo的共享機制、統一管理及協作成本低等優勢，顯然更符合深陷復雜產品線挑戰的數堆疊前端團隊的需求，選擇Monorepo也是團隊探索效率提升的必然道路，

三、合適才最好 Monorepo方案規劃

確定了新的管理方式后，接下來面對的就是如何與數堆疊相適配的問題，市面上關于Monorepo的解決方案和相關工具有很多，雖然rush、nx 之類的工具能夠在特定的領域提供較好的解決方案，但卻并不符合我們的實際需求，

在調研了社區的各種Monorepo實作和解決方案之后，結合我們自身的業務場景和需求，最終我們選擇了pnpm和turborepo作為底層的包管理工具和任務調度工具，因為只有最合適的產品才是最好的解決方案，

● 包管理工具-pnpm

在前端社區中，npm、 yarn、 pnpm 三個包管理工具三足鼎立，而我們最終選擇了pnpm原因在于：pnpm對monorepo有著較好的支持，同時對比其他兩個包管理工具，pnpm在性能等各個方面有著顯著的優勢：

● 任務調度工具-turborepo

任務調度方面，社區中也存在很多優秀的工具，如 rush、nx、lerna、turborepo等，綜合對比之后，我們選擇了配置簡單易懂、調度更加科學的turborepo作為我們的任務調度工具：

四、不斷探索 Monorepo落地實踐

在確定了底層包管理工具和任務調度工具后，數堆疊&Monorepo整體架構方案也就明確了：

Monorepo解決了之前使用Multirepo時存在的問題，幫助我們更好的管理代碼，接下來我們將結合Multirepo存在的問題來詳細說明Monorepo是如何在數堆疊產品中落地的，

● 統一配置

Multirepo存在的一個顯著問題是配置的不統一導致的難以維護，所以我們需要對格式化、代碼檢測、打包等相關流程的配置進行規范化和統一，同時針對不同產品線的細微差別，也需要支持其靈活的擴展，因此我們在Monorepo倉庫的根目錄提供了統一的基礎配置，同時如需要進行調整，不同產品線可以繼承該配置并進行必要的修改，

● 邏輯復用

Multirepo存在的另一個顯著問題就是邏輯難以復用，遷移之前的邏輯復用主要是靠抽象到私有包并發布，或者直接復制粘貼，整體效率低，流程長且難以維護，遷移之后我們對各種配置等進行了統一的同時，也將公用的業務邏輯和組件整合到了倉庫根目錄的packages目錄下，同時通過pnpm的 workspace protocal 鏈接到各個產品線中以復用，這樣不僅解決了邏輯復用的相關問題，同時私有源也不用進行維護，Multirepo下的私有源維護成本問題得以解決，

● 權限校驗

當基礎配置和公共邏輯被暴露出來之后，就面臨著這些內容可以被隨意修改的問題，而這往往會影響所有的產品線，稍有不慎會有造成巨大損失，因此我們需要給這些重要的內容施以限制和保護，

我們基于git hooks做了一些作業，在pre-commit和pre-push階段分別對權限和分支名等內容進行了校驗，并定義了Maintainer、Owner、Deverloper 三個角色，對應的權限分別為：

• Maintainer: 擁有全部權限，可以修改包括基礎組態檔等的所有內容，

• Owner: 各產品線或者公共組件主要負責人，擁有對應范圍內的所有權限，

• Developer: 該產品線或者公共組件的輔助開發人員，只擁有包括開發新功能等的部分產品線權限，

角色權限進行明確的劃分之后，我們可以將基礎配置和公共邏輯等內容的修改交給更有經驗的工程師，同時權限分配配置維護在本地，這樣可以更清晰的了解不同產品線對應的人員，方便溝通，

● 自動化遷移

從 Multirepo遷移到 Monorepo如果采用手動的方式逐個遷移會有如下問題:

1.遷移前的各產品線倉庫存在多個版本需要維護，手動遷移多個版本作業內容重復且效率較低，

2.人為的操作往往會出錯，且出錯時溝通成本較高，

因此我們在遷移的程序中實作了自動化的遷移流程，主要流程如下:

1.自動克隆原倉庫的目標分支內容到Monorepo洗掉需要統一的配置如commitlint等配置；

2.洗掉需要統一的配置如commitlint等配置；

3.洗掉babel, webpack等相關重復依賴；

4.檢測并替換通過pnpm的 workspace protocal 鏈接的內部依賴引入方式；

5.洗掉yarn,npm相關的lock檔案，并安裝依賴生成最新的pnpm-lock.yaml.

自動化遷移的實作，保證了遷移程序的快速且順利的進行，各產品線的同學可以較為平滑的過渡到新的Monorepo專案管理方式，

五、寫在最后

數堆疊前端團隊在今年上半年正式遷移到了Monorepo，解決了之前Multirepo專案管理方式下的私有源維護成本較高，工具/配置等不統一，邏輯復用鏈路長且難以維護等問題，在遷移的程序中，實作了大部分遷移作業的自動化進行，并對重要的配置等進行了權限校驗以進行限制和保護，整體提升了數堆疊前端團隊研發的效率，降低了協作和溝通成本，有效實作降本增效，

袋鼠云開源框架釘釘技術交流qun（30537511），歡迎對大資料開源專案有興趣的同學加入交流最新技術資訊，開源專案庫地址：https://github.com/DTStack

標籤：其他

上一篇：MySQL查詢性能優化七種武器之索引下推

下一篇：淺談SQL中的回圈