一

背景

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

二

前期調(diào)研

在做大倉權(quán)限設(shè)計的時候，前期做了很多的調(diào)研，也參考了國內(nèi)和國外的一些技術(shù)文章，總結(jié)起來主要是基于以下三點的設(shè)計思路去實現(xiàn)：

文件系統(tǒng)的自研，能夠做到文件讀寫權(quán)限的完全控制：對于文件系統(tǒng)的自研，國外的最佳實踐不外乎是 Google 和 Meta，他們都是大倉實踐的典范。對于文件系統(tǒng)的權(quán)限控制，有一套自研的文件系統(tǒng)，能夠?qū)诵拇a和配置文件做到讀寫權(quán)限控制。在 Google 發(fā)表的一篇論文《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 內(nèi)部自研了 Piper，能夠支持基于文件級別的訪問控制列表，大多數(shù)倉庫對所有 Piper 用戶可見，但是重要的配置文件或包含業(yè)務(wù)關(guān)鍵算法的文件可以進行更嚴(yán)格的控制，并且對 Piper 中的文件的讀寫訪問都會被記錄。

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

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

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

三

設(shè)計實現(xiàn)

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

分支模型的定義

分支模型的定義即不同業(yè)務(wù)域在大倉下文件目錄的定義，清晰的目錄結(jié)構(gòu)和文件命名規(guī)范是非常重要的，研發(fā)可以很快速的檢索到所需的文件。前端大倉的分支模型定義如下：

Apps：各業(yè)務(wù)域的目錄結(jié)

_Share：業(yè)務(wù)域下通用依賴目錄

Abroad-Crm-Micro：具體應(yīng)用名

...：后續(xù)新增的應(yīng)用都在業(yè)務(wù)域目錄下

Components：業(yè)務(wù)域下通用組件目錄（初始化固定目錄）

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

Global：國際業(yè)務(wù)域應(yīng)用目錄

...：后續(xù)新增的業(yè)務(wù)域目錄都在 App目錄下

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

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

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

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

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

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

角色權(quán)限的分配

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

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

Maintainer：即代碼倉庫的維護者，可以管理項目的代碼、問題、合并請求等。可以創(chuàng)建和管理分支，添加和刪除文件，創(chuàng)建和關(guān)閉問題，合并和推送分支等。維護者不能更改項目的訪問級別或添加新的維護者；權(quán)限配置角色為TL/PM。

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

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

文件目錄權(quán)限配置

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

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

.husky/ 表示 .husky 目錄下的文件變更，必須由具體的文件 Owner 評審?fù)ㄟ^才可以 MR；

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

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

研發(fā)流程的權(quán)限控制

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

保護分支

在大倉研發(fā)模式下，主要有四類分支，其命名規(guī)范如下：

Dev 分支命名規(guī)范：feature-[應(yīng)用標(biāo)識]-版本號-自定義

測試分支命名規(guī)范：test-[應(yīng)用標(biāo)識]-版本號

發(fā)布分支命名規(guī)范：release-[應(yīng)用標(biāo)識]-版本號

熱修復(fù)分支命名規(guī)范：hotfix-[應(yīng)用標(biāo)識]-版本號

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

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

鉤子函數(shù)

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

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

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

MR&CodeReview

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

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

CodeReview 階段通過文件 Owner 權(quán)限的校驗，確保非本身業(yè)務(wù)域被修改之后被其他業(yè)務(wù)域的 Owner 知悉。

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

通過上面對研發(fā)流程中的權(quán)限控制，避免了出現(xiàn)本地代碼構(gòu)建和生產(chǎn)環(huán)境構(gòu)建不一致的情況，確保了提交代碼的質(zhì)量和穩(wěn)定性。

四

擴展思路

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

訪問控制列表

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

VSCode設(shè)置文件隱藏

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

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

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

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

MAC下隱藏文件

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

chflags hidden **/scripts

上面的 shell 命令表示隱藏大倉下的 scripts 目錄。結(jié)合大倉研發(fā)模式下提供的代碼按需拉取能力，可以在代碼拉取的最后環(huán)節(jié)執(zhí)行如上的命令，就可以隱藏對應(yīng)的文件。

存在的問題：如果懂 MAC 下文件顯隱的設(shè)置，可以在 shell 終端上執(zhí)行 chflags nohidden **/scripts ，這樣 scripts 就會變?yōu)榭梢娏耍_(dá)不到最終的效果。

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

文件訪問日志

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

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

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

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

五

總結(jié)

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

審核編輯：黃飛