Bitbucket 中的角色與權限

角色與權限

在公有云中，只要是註冊用戶，通常都有權利發起一個項目，可以邀請其他用戶進入項目扮演不同的角色。在一個開源項目中，常見的角色有項目發起人或者維護者、核心開發者、貢獻者、測試人員、文檔撰寫者、翻譯者、佈道者、使用者。

儘管角色眾多，但實際項目中，一個人可能身兼數職。角色的劃分並非嚴格，主要用於幫助理解項目成員的職責和分工。然而，在企業組織中，角色與權限通常具有較強關聯。企業角色不會像開源項目那樣豐富，但對權限非常重視。因此，企業角色不僅限於項目本身，還會包含組織架構的隱藏屬性。

Bitbucket 的角色和權限管理非常靈活，可以滿足各種組織和團隊的需求。在Bitbucket 中，權限分為全局級別、項目級別和倉庫級別。這種分級結構確保了權限管理的簡單性和易用性，同時保證了安全性。與權限級別對應的是Bitbucket 上不同級別的管理員，包括系統管理員（管理員）、項目管理員和倉庫管理員。

系統管理員

系統管理員擁有全局權限，主要控制用戶在整個Bitbucket 實例中的訪問權限，如管理用戶、項目和倉庫。其主要職責是對用戶及用戶組的管理，以及相應的權限分配與控制。部分項目中的特定角色也可由系統管理員分配。此外，系統管理員需要統一處理各個賬號的安全配置。

除此之外，系統管理員還需對系統進行配置，備份策略是必不可少的。雖然Bitbucket 基於分佈式的版本控制平台，但實際場景中，倉庫數量眾多，想通過各個本地倉庫恢復Bitbucket 數據是極為困難的。

若遇到需查看審計日誌的特殊情況，系統管理員可提供協助。

在企業中，管理者通常希望所有項目和倉庫採用統一標準，包括權限、分支策略、評審檢查策略等。除非是特殊項目，否則項目管理員也希望能有默認配置減輕初始化項目和倉庫的負擔。這些配置需要經驗豐富的研發管理者準確給出。因此，在常規操作中，這類研發管理者通常也擁有系統管理員權限。當然，系統管理員也可以向各個管理者收集需求，然後匯總總結。這對系統管理員來說有一定能力上的要求，需要深入了解研發場景和思維。

代碼評審流程相對來說，需求場景會比較複雜。除非一開始研發團隊就對所有成員的提交行為進行嚴格管理，否則，隨著技術債的積累，代碼評審流程就會隨著不同項目而產生一定變化。因此，系統管理員通常只能製定一個大家覺得合適的流程配置，然後由項目管理員各自微調。儘管這聽起來並不是最佳做法，但這種現象非常普遍，因為公司不同項目團隊的技術與經驗都不盡相同，很難對代碼評審的嚴格度保持一致。但至少，一個團隊願意重視代碼評審流程，這是一個好的信號。

系統管理員還有一個非常重要的工作就是管理Bitbucket 的插件。只不過，通常使用Bitbucket 的團隊都用上了Atlassian 其他產品，所以有很多功能需求都通過集成滿足了，無需過多的插件。我們在後面的章節中介紹一些場景的時候，會看到一些。

項目管理員

與系統管理員相比，項目管理員的工作更具體，例如創建倉庫、項目相關的安全與權限、分支管理以及代碼合併檢查要求等。

雖然有不少配置在全局權限時已經設定了默認值，但不同的項目終究存在不同之處。項目管理員在默認配置上做些微調再合適不過了。

這樣的角色是否由系統管理員兼任，取決於團隊的規模。小型團隊由於組織架構扁平化，人員較少，通常都會由技術負責人擔任，因此他們對於研發項目流程上的規則也具有相當的話語權。中大型團隊由於分工明細，不同的研發項目會由不同的人擔任。所以，項目管理員需要選擇遵守為先，微調的部分得到認可後再進行。

在管理分支問題上，雖然不會有爭議點，因為技術負責人很明白業界的標準，但普遍認為Git Flow 過於復雜，而GitHub Flow 又不是所有團隊都能適用，因此會傾向於類似GitLab Flow 的環境分支。

工具人學堂的顧問會在充分了解研發團隊的運行模式以及產品架構之後，通常會推薦團隊可以從業界標准開始遵循，隨著團隊的成長，再調整流程，實現敏捷迭代。但大多數的技術負責人，均希望從一開始就擁有一個成熟的分支模型，既希望擁有GitLab Flow 中的環境概念，又想擁有Git Flow 中的多分支管理理念，同時還希望能夠像GitHub Flow 般簡潔。

儘管這樣的想法並非錯誤，但工具人學堂的顧問始終希望客戶能理解並認識到，對於一個成長型團隊來說，工作流是不斷演變的。因此，如果無法明確自己的分支管理流程，那麼工具人學堂的顧問會建議先遵循一個業界標準，隨著團隊的成長，再逐步調整流程。這意味著在一開始就設計一個完美的工作流是不必要的，實際上這也是一個敏捷迭代的過程。

這種思路也可以應用於代碼評審的檢查要求。至於是先嚴後鬆，還是先鬆後嚴，這取決於團隊當前的技能水平。先嚴後鬆可能會影響研發進度，而先鬆後嚴會導致技術債積累。作為顧問，我們只能提醒這些選擇所帶來的影響，提出建議，但無法替客戶做出最終決策。

倉庫管理員

在所有管理員中，倉庫管理員的權限範圍最窄，只對倉庫負責。如今微服務架構已經被廣泛接受，甚至是濫用，為了方便管理，很多團隊會選擇每個服務都是一個獨立的代碼庫，如此一來倉庫成員或關注者可能總共就個位數，這與單體應用軟件項目中存在大量成員的情況完全不一樣。所以倉庫管理員有時候就直接被授予了當前倉庫的開發者。

當然，有些企業組織架構很嚴謹，對於權限管控也有很高的要求。他們從一開始搭建時就按照組織架構來設定用戶組及權限，這樣的情況下，非常大的概率項目管理員和倉庫管理員會是同一個人來擔任，負責統一管理分配項目及各倉庫的權限。