Bitbucket 中的角色与权限
角色与权限
在公有云中，只要是注册用户，通常都有权利发起一个项目，可以邀请其他用户进入项目扮演不同的角色。在一个开源项目中，常见的角色有项目发起人或者维护者、核心开发者、贡献者、测试人员、文档撰写者、翻译者、布道者、使用者。
尽管角色众多，但实际项目中，一个人可能身兼数职。角色的划分并非严格，主要用于帮助理解项目成员的职责和分工。然而，在企业组织中，角色与权限通常具有较强关联。企业角色不会像开源项目那样丰富，但对权限非常重视。因此，企业角色不仅限于项目本身，还会包含组织架构的隐藏属性。
Bitbucket 的角色和权限管理非常灵活，可以满足各种组织和团队的需求。在 Bitbucket 中，权限分为全局级别、项目级别和仓库级别。这种分级结构确保了权限管理的简单性和易用性，同时保证了安全性。与权限级别对应的是 Bitbucket 上不同级别的管理员，包括系统管理员（管理员）、项目管理员和仓库管理员。
系统管理员
系统管理员拥有全局权限，主要控制用户在整个 Bitbucket 实例中的访问权限，如管理用户、项目和仓库。其主要职责是对用户及用户组的管理，以及相应的权限分配与控制。部分项目中的特定角色也可由系统管理员分配。此外，系统管理员需要统一处理各个账号的安全配置。
除此之外，系统管理员还需对系统进行配置，备份策略是必不可少的。虽然 Bitbucket 基于分布式的版本控制平台，但实际场景中，仓库数量众多，想通过各个本地仓库恢复 Bitbucket 数据是极为困难的。
若遇到需查看审计日志的特殊情况，系统管理员可提供协助。
在企业中，管理者通常希望所有项目和仓库采用统一标准，包括权限、分支策略、评审检查策略等。除非是特殊项目，否则项目管理员也希望能有默认配置减轻初始化项目和仓库的负担。这些配置需要经验丰富的研发管理者准确给出。因此，在常规操作中，这类研发管理者通常也拥有系统管理员权限。当然，系统管理员也可以向各个管理者收集需求，然后汇总总结。这对系统管理员来说有一定能力上的要求，需要深入了解研发场景和思维。
代码评审流程相对来说，需求场景会比较复杂。除非一开始研发团队就对所有成员的提交行为进行严格管理，否则，随着技术债的积累，代码评审流程就会随着不同项目而产生一定变化。因此，系统管理员通常只能制定一个大家觉得合适的流程配置，然后由项目管理员各自微调。尽管这听起来并不是最佳做法，但这种现象非常普遍，因为公司不同项目团队的技术与经验都不尽相同，很难对代码评审的严格度保持一致。但至少，一个团队愿意重视代码评审流程，这是一个好的信号。
系统管理员还有一个非常重要的工作就是管理 Bitbucket 的插件。只不过，通常使用 Bitbucket 的团队都用上了 Atlassian 其他产品，所以有很多功能需求都通过集成满足了，无需过多的插件。我们在后面的章节中介绍一些场景的时候，会看到一些。
项目管理员
与系统管理员相比，项目管理员的工作更具体，例如创建仓库、项目相关的安全与权限、分支管理以及代码合并检查要求等。
虽然有不少配置在全局权限时已经设定了默认值，但不同的项目终究存在不同之处。项目管理员在默认配置上做些微调再合适不过了。
这样的角色是否由系统管理员兼任，取决于团队的规模。小型团队由于组织架构扁平化，人员较少，通常都会由技术负责人担任，因此他们对于研发项目流程上的规则也具有相当的话语权。中大型团队由于分工明细，不同的研发项目会由不同的人担任。所以，项目管理员需要选择遵守为先，微调的部分得到认可后再进行。
在管理分支问题上，虽然不会有争议点，因为技术负责人很明白业界的标准，但普遍认为 Git Flow 过于复杂，而 GitHub Flow 又不是所有团队都能适用，因此会倾向于类似 GitLab Flow 的环境分支。
工具人学堂的顾问会在充分了解研发团队的运行模式以及产品架构之后，通常会推荐团队可以从业界标准开始遵循，随着团队的成长，再调整流程，实现敏捷迭代。但大多数的技术负责人，均希望从一开始就拥有一个成熟的分支模型，既希望拥有 GitLab Flow 中的环境概念，又想拥有 Git Flow 中的多分支管理理念，同时还希望能够像 GitHub Flow 般简洁。
尽管这样的想法并非错误，但工具人学堂的顾问始终希望客户能理解并认识到，对于一个成长型团队来说，工作流是不断演变的。因此，如果无法明确自己的分支管理流程，那么工具人学堂的顾问会建议先遵循一个业界标准，随着团队的成长，再逐步调整流程。这意味着在一开始就设计一个完美的工作流是不必要的，实际上这也是一个敏捷迭代的过程。
这种思路也可以应用于代码评审的检查要求。至于是先严后松，还是先松后严，这取决于团队当前的技能水平。先严后松可能会影响研发进度，而先松后严会导致技术债积累。作为顾问，我们只能提醒这些选择所带来的影响，提出建议，但无法替客户做出最终决策。
仓库管理员
在所有管理员中，仓库管理员的权限范围最窄，只对仓库负责。如今微服务架构已经被广泛接受，甚至是滥用，为了方便管理，很多团队会选择每个服务都是一个独立的代码库，如此一来仓库成员或关注者可能总共就个位数，这与单体应用软件项目中存在大量成员的情况完全不一样。所以仓库管理员有时候就直接被授予了当前仓库的开发者。
当然，有些企业组织架构很严谨，对于权限管控也有很高的要求。他们从一开始搭建时就按照组织架构来设定用户组及权限，这样的情况下，非常大的概率项目管理员和仓库管理员会是同一个人来担任，负责统一管理分配项目及各仓库的权限。
