前端大倉monorepo權限設計思路和實現方案

一

背景

前端 monorepo 在試行大倉研發流程過程中，已經包含了多個業務域的應用、共享組件庫、工具函數等多種靜態資源，在實現包括代碼共享、依賴管理的便捷性以及更好的團隊協作的時候，也面臨大倉代碼文件權限的問題。如何讓不同業務域的研發能夠順暢的在大倉模式下開發，離不開有效的權限管理方法。好的權限管理方法能夠確保研發同學輕松找到和理解項目的不同部分，而不受混亂或不必要的復雜性的影響，并且也應該允許研發同學合作并同時工作，同時也要確保代碼合并的更改經過代碼審查，以維護代碼的質量和穩定性。本文通過實踐過程中遇到的一些問題以及逐步沉淀下來的最佳實踐，來闡述下前端大倉 monorepo 在權限這塊是如何思考以及設計的。

二

前期調研

在做大倉權限設計的時候，前期做了很多的調研，也參考了國內和國外的一些技術文章，總結起來主要是基于以下三點的設計思路去實現：

文件系統的自研，能夠做到文件讀寫權限的完全控制：對于文件系統的自研，國外的最佳實踐不外乎是 Google 和 Meta，他們都是大倉實踐的典范。對于文件系統的權限控制，有一套自研的文件系統，能夠對核心代碼和配置文件做到讀寫權限控制。在 Google 發表的一篇論文《Why Google stores billions of lines of code in a single repository》中也有提到：

Since Google’s source code is one of the company’s most important assets, security features are a key consideration in Piper’s design. Piper supports file-level access control lists. Most of the repository is visible to all Piper users;d however, important configuration files or files including businesscritical algorithms can be more tightly controlled. In addition, read and write access to files in Piper is logged. If sensitive data is accidentally committed to Piper, the file in question can be purged. The read logs allow administrators to determine if anyone accessed the problematic file before it was removed.

大致的意思是 Google 內部自研了 Piper，能夠支持基于文件級別的訪問控制列表，大多數倉庫對所有 Piper 用戶可見，但是重要的配置文件或包含業務關鍵算法的文件可以進行更嚴格的控制，并且對 Piper 中的文件的讀寫訪問都會被記錄。

基于Git提供的鉤子函數，能做到文件寫權限的控制：Git 本身是一個分布式文件系統，其提供了代碼研發流程中的各種鉤子函數，在不同的鉤子函數里面對文件的修改做校驗，可以做到代碼文件寫權限的控制，但是做不到代碼文件的讀權限控制；

基于Gitlab的能力，對文件目錄權限做控制：Gitlab 開始引入了“Protected Environments”的概念，即允許為具體的文件或目錄設置權限，并指定哪些用戶或用戶組擁有文件的“Maintainer”權限，以便管理文件的更改和合并請求，可以用于更細粒度的文件級別權限控制。當然此種方法也只能做到代碼文件寫權限的控制，做不到代碼文件的讀權限控制。

從上面的三種調研實現來看，如果要完全做到文件系統的讀寫權限控制，勢必需要自研一套適合研發流程及業務體系的文件系統，這種實現成本會很大，且基于實際的應用場景去考慮，也不是很有必要。所以本文主要圍繞基于Git提供的鉤子函數和基于Gitlab的能力來闡述過程中是如何實踐的。

三

設計實現

在前端 monorepo 實踐過程中，對于權限模塊的設計如果考慮不好的話，會帶來很不好的研發體驗，同時權限的實現不僅僅是代碼邏輯層面，需要考慮很多方面。在實踐過程中，具體考慮了分支模型的定義、角色權限的分配、文件目錄權限以及研發流程的權限控制四個方面。

分支模型的定義

分支模型的定義即不同業務域在大倉下文件目錄的定義，清晰的目錄結構和文件命名規范是非常重要的，研發可以很快速的檢索到所需的文件。前端大倉的分支模型定義如下：

Apps：各業務域的目錄結

_Share：業務域下通用依賴目錄

Abroad-Crm-Micro：具體應用名

...：后續新增的應用都在業務域目錄下

Components：業務域下通用組件目錄（初始化固定目錄）

...：可以自定義擴展目錄

Global：國際業務域應用目錄

...：后續新增的業務域目錄都在 App目錄下

Packages：前端平臺通用組件、工具函數、配置文件、Hooks 依賴

Components：平臺通用組件目錄（初始化固定目錄）

Hooks：平臺通用 Hooks 目錄（初始化固定目錄）

...：可以自定義擴展目錄

通過使用語義化的文件和目錄命名，減少了混淆和錯誤，使得分支模型的定義更加的清晰，研發成員也可以很清楚的知道自己所關注的業務應用在哪個目錄下，同時如果需要看其他業務域的代碼，也很容易檢索到。

上面只是大倉 B 端應用的分支模型定義，目前融合了 C 端 H5 應用以及 Node 服務應用之后，大倉目錄的劃分會相對比較復雜的多，這里不再具體贅述。

角色權限的分配

在大倉模式下，角色權限沒有另辟蹊徑，還是沿用 Gitlab 已有的權限配置：Owner、Maintainer 和 Developer。

Owner：即代碼倉庫的所有者，所有者是擁有最高權限的角色，可以對項目進行完全控制。他們可以添加和刪除項目成員，修改項目設置，包括訪問級別、分支保護規則和集成設置等。只有項目的所有者才能轉讓或刪除項目；權限配置角色為TL。

Maintainer：即代碼倉庫的維護者，可以管理項目的代碼、問題、合并請求等?？梢詣摻ê凸芾矸种?，添加和刪除文件，創建和關閉問題，合并和推送分支等。維護者不能更改項目的訪問級別或添加新的維護者；權限配置角色為TL/PM。

Developer：即代碼倉庫的開發者，是項目的一般成員，具有對代碼進行修改和提交的權限。他們可以創建和分配問題、合并請求，查看代碼、提交變更以及推送和拉取分支等。權限配置角色為研發人員。

這里需要考慮的是只要開發者具備 Developer 權限，那么他就可以修改大倉任何目錄下的代碼，并且本地可以提交，這樣會導致本地源碼依賴出現很大的風險：會出現本地代碼構建和生產環境構建不一致的情況，在研發流程意識不強的情況下很容易引發線上問題。本著對代碼共享的原則，對于代碼文件讀權限不做控制，也允許研發修改代碼，但是對修改的代碼的發布會做流程上的強管控。這里就會涉及到 Gitlab 的分支保護機制以及文件 Owner 權限配置。

文件目錄權限配置

在 GitLab 未支持文件目錄權限設置之前，對于文件目錄權限的控制主要依賴 Git 的鉤子函數，在代碼提交的時候，對暫存區的變更文件進行識別并做文件權限校驗，流程設計也不怎么復雜，只需要額外再開發文件目錄和研發的權限映射配置平臺即可。在 GitLab 開始支持文件目錄權限設置，可以用于更細粒度的文件級別的權限控制，內部就支持文件目錄和研發的權限映射關系，其配置頁面如下：

當有對應的文件或者目錄路徑下的文件變更的時候，在CodeReview過程中必須由對應的 Owner 成員確認無誤之后，才可以MR代碼。比如：

.husky/ 表示 .husky 目錄下的文件變更，必須由具體的文件 Owner 評審通過才可以 MR；

Apps/XXX/crm/ 表示 Apps/XXX/crm 目錄下的文件變更，必須由對應的文件 Owner其中之一審批通過才可以 MR。

通過 GitLab 提供的文件目錄權限配置，即使研發可以修改任意目錄下的文件代碼，但是最終在CodeReview的流程中，需要對應的文件 Owner 進行確認評審，這樣就避免了研發在不注意的情況下，提交了原本不該變更的文件的代碼，同時也避免了線上問題的發生。

研發流程的權限控制

前面提到的分支模型的定義、角色權限的分配以及文件目錄權限的配置都是需要約定俗成的，但是在真實的研發過程中，需要考慮的場景會復雜的多。比如研發可以繞開 MR 的流程，直接本地合并代碼到發布分支。對于這類場景，對大倉下的分支做了規范約束以及 MR&CodeReview 流程中的強管控。

保護分支

在大倉研發模式下，主要有四類分支，其命名規范如下：

Dev 分支命名規范：feature-[應用標識]-版本號-自定義

測試分支命名規范：test-[應用標識]-版本號

發布分支命名規范：release-[應用標識]-版本號

熱修復分支命名規范：hotfix-[應用標識]-版本號

其中 Feature 分支為開發分支，由 Developer 創建和維護；Release 和 Hotfix分支為保護分支，Developer 和 Maintainer 都可以創建，但是 Developer 角色沒有權限直接將 Feature 分支合入 Release 或者 Hotfix 分支，只能由 Maintainer 角色來維護?；谀壳安煌瑯I務域會經常創建 test 分支用于不同測試環境的部署，這里 test 分支并未設置為保護分支。當然 Matser 分支也是保護分支，只有 Owner 角色才有權限直接將分支代碼合并到主干分支。

通過對不同類型的分支的定義，基于 GitLab 提供的保護分支能力，避免了研發本地合并代碼的情況，使得 Feature 分支的代碼必須走研發流程的 MR&CodeReview 流程，才能最終合入代碼。

鉤子函數

通過保護分支的約束，避免了本地直接合發布分支帶來的風險，但是在本地代碼提交的過程中，如果不做權限的校驗，就會在CodeReview流程中出現文件 Owner 權限不足的情況，為了在代碼提交階段就能識別到非變更文件的提交，這里基于 Git 的鉤子函數，做了權限校驗，其流程如下：

通過 Git Hooks 提供的 Pre-Commit 和 Pre-Push 兩個節點做權限校驗，防止出錯。Pre-Commit 不是必須的，如果影響代碼提交的效率，可以跳過這個步驟，Pre-Push 是必須的，不允許非 Owner 做本地發布。

當然這里也會帶來一個問題：當迭代的 Release 分支落后于 Master 分支，此時基于 Master 分支創建的 Feature 分支就會和 Release 分支代碼不一致，導致出現很多非必要的變更文件，此時研發會很疑惑為什么會出現沒有修改過的變更文件。這個問題在大倉研發模式下是無法避免的，通過分析之后，在本地提交階段，過濾了 Apps 目錄的校驗，只保留了大倉頂層部分核心文件的權限校驗，因為大部分的變更都在業務域下的應用里面，頂層的文件很少會去修改。

MR&CodeReview

通過保護分支的約束以及鉤子函數對部分核心文件的校驗，減少了很多在 MR&CodeReview 中本該遇到的問題。基于文件 Owner 權限的 MR 和 CodeReview 流程：Commit 階段 -> Push 階段 -> 創建 MR -> CodeReview -> 執行 MR，每個階段的流程如下：

Commit 階段通過對核心文件的 Owner 校驗，避免核心文件被亂改的情況；

CodeReview 階段通過文件 Owner 權限的校驗，確保非本身業務域被修改之后被其他業務域的 Owner 知悉。

這里會帶來一個問題：當 Release 分支回合 Master 代碼的時候，會創建臨時 MR，這個過程也會有文件 Owner 權限的校驗（比如客服同學同步代碼的時候，也會將商家和供應鏈的代碼一起同步過來），就需要其他業務域的文件 Owner CR 通過才行，但 Master 的代碼實際已經是 CR 過的，沒有必要重復 CR，并且同步頻繁的時候，會經常 CR 確認，導致回合代碼的效率非常低。這里給效率技術那邊提了需求，在 Release 分支回合 Master 代碼的時候，不做文件 Owner 的校驗。

通過上面對研發流程中的權限控制，避免了出現本地代碼構建和生產環境構建不一致的情況，確保了提交代碼的質量和穩定性。

四

擴展思路

通過以上的設計實現，基本上大倉下的權限設計能滿足現有的研發模式了。為了彌補文件讀權限控制的缺陷，過程中，也考慮了訪問控制列表以及文件訪問日志的實現，但是最終覺得不是很有必要，就沒有在大倉里面應用起來。這里可以分享下訪問控制列表以及文件訪問日志實現的幾種思路。

訪問控制列表

訪問控制列表即大倉下對文件目錄的訪問控制，以便更精確地控制對敏感信息或關鍵代碼的訪問。之前有提到 Google 和 Meta 都是通過自研的文件系統實現，但是如果不是自研，是不是就一定實現不了了呢，其實未必見得。

VSCode設置文件隱藏

通過在大倉目錄下的 .vscode/settings.json 文件配置 files.exclude 屬性可以實現文件的顯隱，如下：

{
  "files.exclude": {
    "**/scripts": true
  }
}

上面的配置表示大倉目錄下的scripts目錄是不可見的。

存在的問題： 如果懂 .vscode/settings.json 配置的研發，可以直接本地將 True 改為 False，這里配置就失效了。還有并不是所有研發都是用的 VSCode IDE，還有不少研發用其他的 IDE，每個人的研發習慣不一樣，很難做到強約束。

MAC下隱藏文件

MAC 下可以通過 shell 命令設置文件的顯隱，如下：

chflags hidden **/scripts

上面的 shell 命令表示隱藏大倉下的 scripts 目錄。結合大倉研發模式下提供的代碼按需拉取能力，可以在代碼拉取的最后環節執行如上的命令，就可以隱藏對應的文件。

存在的問題：如果懂 MAC 下文件顯隱的設置，可以在 shell 終端上執行 chflags nohidden **/scripts ，這樣 scripts 就會變為可見了，達不到最終的效果。

對于訪問權限列表的控制，實際上是可以通過一些其他的方式實現，但其實現思路基本都是治根不治本，起不了多大的作用，所以最后都沒有在大倉的研發流程里面體現。

文件訪問日志

文件訪問日志即當研發打開文件的時候，發送一條日志到服務端并保存下來，這樣可以對包含敏感信息的配置文件進行監聽， 設置審計日志和監控，以便跟蹤誰做了什么操作，并在出現異常情況時能夠快速識別和應對問題。通過 VSCode 插件是可以實現的，VSCode 啟動之后，提供了對應文件目錄路徑的打開事件 onDidOpenTextDocument，當研發打開任何文件的時候，都可以觸發監聽事件，那么我們就能在監聽事件里面去做日志發送相關的邏輯，實現文件訪問日志記錄的功能，大致的實現如下：

export function monitorPermissionOfTargetFile(targetFilePath: string, repoRootPath: string) {
  const targetFileFullPath = repoRootPath + targetFilePath;
  // 打開項目目錄下任意文件的回調函數
  vscode.workspace.onDidOpenTextDocument(textDocument => {
    // 獲取被打開的文件路徑
    const filePath = textDocument.uri.fsPath;
    if (filePath === targetFileFullPath) {
      // 添加日志發送邏輯
    }
  });
}

存在的問題：該功能強依賴 VSCode IDE，只有在 VSCode 里面才能實現，并非所有的研發都在用 VSCode，并且實時監聽文件的點擊事件也會帶來一定的系統開銷成本?，F在本來打開多個 VSCode IDE，電腦運行就比較慢了，再加上該功能，性能損耗估計會更多。

上面只是提供了大倉權限實踐過程中未落地的兩個擴展思路，如果還有其他更好的思路能實現文件的讀權限控制，歡迎隨時溝通交流。

五

總結

前端 monorepo 大倉的權限設計在實現的過程中，遇到了很多的問題，有些時候想的很好，但是實際在研發流程中會因不同的業務域場景存在不一樣的問題。比如基于 Master 新建 Feature 分支還是基于 Release 新建 Feature 分支這個問題就尤其突出，起初基于 Master 新建的 Feature 分支，帶來的問題是研發在合 Release 分支的時候，有很多非變更文件，導致 CR 都不清楚具體要看哪些文件；然后改成基于 Release 新建的 Feature 分支，帶來的問題是會遺漏部分已發版的 Release 分支代碼；最后綜合考慮還是基于 Master 新建的 Feature 分支。大倉的權限設計也離不開參與研發流程改造的小伙伴以及效能技術的小伙伴，過程中為了適配大倉的權限，做了很多研發流程的改造以及GitLab能力的擴展，希望本文能給讀者帶來一定的幫助。

審核編輯：黃飛