我們是袋鼠雲數棧 UED 團隊，致力於打造優秀的一站式數據中台產品。我們始終保持工匠精神，探索前端道路，為社區積累並傳播經驗價值。 本文作者：星野 困境頻生前端代碼管理何解？ 前端代碼管理一直是困擾著不少前端開發團隊的難題，從開發到發佈的整體工作流程中，除了常規的技術問題外，往往還伴隨著溝通成本、維 ...
我們是袋鼠雲數棧 UED 團隊，致力於打造優秀的一站式數據中台產品。我們始終保持工匠精神，探索前端道路，為社區積累並傳播經驗價值。
本文作者：星野
困境頻生前端代碼管理何解？
前端代碼管理一直是困擾著不少前端開發團隊的難題，從開發到發佈的整體工作流程中，除了常規的技術問題外，往往還伴隨著溝通成本、維護成本及協作效率等問題。這些問題在團隊規模較小的時候可能不太明顯，但是當團隊規模變大時矛盾就越發凸顯。
數棧前端開發團隊負責著離線開發、實時開發、數據服務、數據資產等多條產品線的開發和維護工作，面對眾多的產品線，如何合理的管理代碼，成了團隊需要思考的問題，雖然藉助了 Multirepo 進行管理，但還是遇到了許多難題：
-
私有源維護成本增加
為復用相關業務邏輯，團隊內部抽象出一些私有包，由於不能在公網暴露，為了管理這些私有包團隊使用了私有源，但由於搭建私有源伺服器資源問題，私有源常常不穩定且下載速度慢，特別是對於需要源碼交付的某些客戶來說，安裝這些私有包更會遇到各種問題，交付的時間和人力成本大大升高。
-
邏輯難復用，重覆造輪子
各個倉庫中會抽象出同一功能的組件，組件之間的共用往往難以同步，造成了「重覆造輪子」現象。
-
工具/配置不統一，溝通成本高
各個倉庫所使用的工具和配置沒有進行統一，在進行配置更新的過程中，往往需要同步到各個產品線負責人，溝通成本較高。
這些問題嚴重拖慢了數棧前端團隊從開發到發佈的整體流程，同時增加了團隊的維護成本和溝通成本，如何尋找新的工具解決這些問題已迫在眉睫，在進行了深入調研和多次討論的過程中，新的項目管理方式 Monorepo 在這時映入了我們的眼帘。
Multirepo VS Monorepo
那麼 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.人為的操作往往會出錯，且出錯時溝通成本較高。因此我們在遷移的過程中實現了自動化的遷移流程，主要流程如下:
- 自動克隆原倉庫的目標分支內容到 Monorepo；
- 刪除需要統一的配置如 commitlint 等配置；
- 刪除 babel, webpack 等相關重覆依賴；
- 檢測並替換，採用pnpm的 workspace protocal 鏈接的內部依賴引入方式；
- 刪除 yarn/npm 相關的 lock 文件，並安裝依賴生成最新的 pnpm-lock.yaml.
自動化遷移的實現，保證了遷移過程的快速且順利的進行，各產品線的同學可以較為平滑的過渡到新的項目管理方式——Monorepo。
寫在最後
數棧前端團隊正式遷移到了 Monorepo，解決了之前 Multirepo 項目管理方式下的私有源維護成本高，工具/配置不統一，邏輯復用鏈路長且難以維護等問題。在遷移的過程中，實現了大部分遷移工作的自動化進行，並對重要的配置等進行了許可權校驗以進行限制和保護。整體提升了數棧前端團隊研發的效率，降低了協作和溝通成本，有效實現了降本增效。
最後
歡迎關註【袋鼠雲數棧UED團隊】~
袋鼠雲數棧 UED 團隊持續為廣大開發者分享技術成果，相繼參與開源了歡迎 star
- 大數據分散式任務調度系統——Taier
- 輕量級的 Web IDE UI 框架——Molecule
- 針對大數據領域的 SQL Parser 項目——dt-sql-parser
- 袋鼠雲數棧前端團隊代碼評審工程實踐文檔——code-review-practices
- 一個速度更快、配置更靈活、使用更簡單的模塊打包器——ko
- 一個針對 antd 的組件測試工具庫——ant-design-testing
