如何大规模地组织和管理 Azure 仓库：Azure DevOps 工程师的指南

为什么仓库组织会成为扩展性难题

许多团队低估了仓库管理的复杂性，因为他们只考虑当前的需求。

一个只开发一个应用程序的初创公司可能只需要：

前端
后端
数据库

这一切看起来都很容易管理。

但两年后，同一家公司可能会需要：

客户门户网站
客户门户API
计费服务
通知服务
认证服务
分析服务
移动应用API
共享组件
设计系统
内部工具

问题不再在于编写代码，而在于如何管理这些代码。

如果没有明确的标准，组织通常会遇到以下问题：

• 仓库的所有权不明确

• 分支策略各不相同

• 安全权限分布混乱

• CI/CD配置重复

• 新员工的入职流程变慢

• Git仓库规模过大且难以管理

• 文档不统一

• 合规审计变得困难

仓库管理的最终目标就是减少运营中的摩擦。每个仓库都应该易于理解、易于保障安全、易于维护，同时也应该能够轻松扩展。

建立以所有权为导向的仓库结构

团队常犯的一个错误就是将仓库组织得像文件夹一样。

创建仓库不应该仅仅是因为需要一个“文件夹”，而应该是由于所有权、部署方式、安全需求或生命周期管理的要求所迫。

在决定是否要新建一个仓库时，可以问自己以下问题：

• 这段代码由谁负责维护？

• 它是如何被部署的？

• 哪些人可以访问它？

• 它的版本是否独立管理？

• 它是否需要不同的安全控制措施？

如果这些问题的答案与其他代码库的情况有很大不同，那么这个代码很可能应该单独被放在一个仓库中。

请把仓库看作是业务资产，而不仅仅是技术工具。

在单仓库与多仓库策略之间做出选择

你首先需要决定的就是：是将所有项目存储在一个仓库中，还是将它们分散到多个仓库里。

这个问题并没有统一的答案。

>

正确的选择取决于所有权和部署需求。

在什么情况下适合使用单仓库

当同一个团队负责所有项目的开发，并且各个组件之间紧密耦合时，单仓库结构会非常适用。

例如：

company-platform/
│
├── frontend/
├── backend/
├── shared-ui/
├── docs/
└── infrastructure/

这种结构能够简化以下操作：

• 依赖关系的管理

• 代码重构工作

• 共享工具的使用

• 协调各个项目的发布流程

但随着团队的发展，单一代码库往往会变得难以管理，因为所有成员都共享同一个代码库结构。

多代码库策略在何种情况下更有效

大型组织通常能从使用多个代码库中受益。

以一个使用Node.js、TypeScript和React构建的SaaS平台为例：与其使用一个庞大的代码库，不如将代码分为以下几个独立的代码库：

customer-portal-web
customer-portal-api
billing-service
notification-service
shared-ui-library
authentication-service

每个代码库都可以：

• 拥有自己的发布周期

• 设置不同的权限规则

• 独立地进行部署

• 实现独立的扩展能力

这种做法与现代微服务架构非常契合。

根据业务边界划分Azure DevOps项目

许多团队虽然正确地创建了代码库，但将所有代码都放在同一个Azure DevOps项目中。

起初这种做法可能效果不错，但日后就会引发各种问题。

Azure DevOps项目应该反映组织内部的业务结构划分。

例如：

Customer Platform
├── customer-web
├── customer-api
├── mobile-api

Internal Systems
├── hr-system
├── payroll-api

Developer Platform
├── shared-components
├── infrastructure-tools

这种结构有助于提升安全性管理、报告机制、合规性要求以及团队工作的自主性。

一个项目应该代表一个明确的业务领域，而不是简单地将多个代码库拼凑在一起。

在代码库数量增加之前制定命名规范

在代码库数量较少时，人们往往认为命名规范并不重要……但当代码库数量达到500个以上时，问题就会显现出来。

如果没有统一的命名规范，开发人员会花费大量时间去查找代码库及其所属团队。

不良的命名示例：

backend
backend-v2
new-api
test-project
final-final-api

良好的命名示例：

sales-order-service
sales-payment-api
customer-auth-service
platform-notification-service
marketing-website

一个简单的命名规则非常有效：

[领域名称]-[服务名称]

例如：

billing-payment-service
billing-invoice-service
customer-auth-service

这样，每个人都能立刻理解该代码库所对应的业务领域、服务功能以及所属团队。

良好的命名规范能够有效避免混淆的发生。

实施跨代码库管理策略，而非单独管理每个代码库

正是在这个环节，许多Azure DevOps环境会开始出现问题。

想象一下，你需要管理100个代码仓库、300名开发人员以及20支开发团队。你会为每一个仓库都手动配置分支策略吗？

当然不会。

然而许多组织仍然在这样做，结果就是导致各种规则之间存在不一致性。

有些仓库要求必须提交拉取请求才能进行代码修改，而另一些仓库则允许直接提交代码；有些仓库要求代码构建必须成功才能合并，而有些仓库则没有这样的要求。

随着时间的推移，这种管理方式会导致代码仓库的质量难以得到统一且持续的保障。

解决这个问题的方法就是实施跨代码仓库的统一管理机制。不应该将各个代码仓库视为独立存在的个体，而应该把相关的策略视作整个组织所遵循的标准。

在多个代码仓库中执行相同的分支策略

随着工程团队的规模不断扩大，维持代码质量的一致性变得越来越困难。

一个只有5名开发人员的代码仓库可能不需要严格的治理机制就能正常运行，但一个拥有数百名开发人员和数十个服务项目的代码仓库体系就绝对无法做到这一点。

如果没有相应的保护措施，开发人员可能会做出以下行为：

• 直接将代码推送到生产环境的分支中

• 绕过代码审查流程

• 合并未经测试的代码

• 无意中引入会导致系统故障的更改

• 在缺乏有效追溯机制的情况下部署新功能

Azure DevOps的分支策略能够通过在代码合并之前强制执行组织标准，从而帮助避免这些问题的发生。

组织应该制定统一的分支管理策略，并在所有代码仓库中一致地应用这些保护措施，而不是为每一个仓库单独配置策略。

哪些分支需要受到保护？

并不是所有的分支都需要同样程度的保护。

大多数团队会重点保护那些直接影响生产环境或客户使用环境的代码分支。

一种常见的保护策略是针对以下这些分支：

main
release/*
hotfix/*

让我们来了解一下为什么这些分支需要被特别保护。

保护主分支

main分支通常代表你的应用程序中最稳定的版本。

对于使用Node.js和TypeScript开发的程序来说，main分支中的代码往往就是最终会被部署到生产环境中的代码。

例如：

main
│
├── 最新的、可用于生产的代码
├── 已通过自动化测试的代码
└── 经过代码审查并获批准的代码

因为main分支直接关系到客户的体验，所以开发人员绝对不能直接将任何更改推送到这个分支中。所有更改都必须通过拉取请求的形式进行提交。

建议采取的保护措施包括：

• 要求必须提交拉取请求

• 需要经过审核人员的批准

• 代码构建必须成功才能合并

• 必须关联相应的任务项

• 禁止强制推送操作

这些措施能够确保所有被部署到生产环境中的代码都经过了充分的审查和验证。

保护发布分支

发布分支通常用于为生产环境的部署做准备。

示例：

release/v1.0
release/v1.1
release/v2.0

这些分支中通常包含那些在部署前正在进行最终测试的代码。

如果没有相应的保护措施，开发人员在稳定发布版本的过程中很可能会不小心引入新的功能或未经测试的变更。

推荐的防护措施包括：

release/*

• 要求提交拉取请求

• 需要质量保障团队的审批

• 必须确保测试成功通过

• 限制直接进行代码提交

这些措施能够保证发布分支的稳定性与可预测性。

保护热修复分支

当生产环境中出现需要立即处理的紧急问题时，就会使用热修复分支。

例如：

• 支付失败

• 认证系统故障

• 安全漏洞

• 严重的应用程序错误

示例：

hotfix/payment-timeout
hotfixauthentication-error

由于热修复分支往往是在压力之下创建的，因此它们更容易出现错误。

团队通常希望尽快完成部署而跳过审核流程，但恰恰正因为如此，保护措施才显得尤为重要。

推荐的防护措施包括：

hotfix/*

• 至少需要一名审核人员参与

• 必须进行自动化测试

• 通过工作项来跟踪所有变更

• 限制直接推送代码

即使在紧急情况下，也应当严格遵守代码质量标准。

在各个仓库中实施统一的策略

想象一下，如果一个组织需要管理以下这些项目：

customer-portal-api
billing-service
notification-service
authentication-service
reporting-service

如果每个仓库的分支规则都不同，开发人员就会感到困惑，管理也会变得十分困难。

因此，团队应该为所有仓库制定统一的标准：

main       → 需要2名审核人员 + 测试通过
release/*  → 需要质量保障团队的审批 + 测试通过
hotfix/*   → 需要1名审核人员 + 测试通过

这样，无论开发人员正在哪个仓库工作，他们都能遵循相同的工作流程。

如果一名开发人员从负责billing-service的项目转到负责notification-service的项目，他/她已经熟悉了合并代码的流程，因为所有地方都适用相同的规则。

通过在Azure的所有仓库中一致地执行这些分支保护措施，组织能够减少生产环境中的问题，提高代码质量，加强安全性，并建立起一个能够随着业务发展而不断扩展的开发工作流程。

在代码投入生产环境之前，必须进行构建验证

许多错误之所以会在生产环境中出现，是因为代码虽然经过了审查，但从未经过自动测试。而构建验证正是为了解决这一问题。

对于一个使用TypeScript和Node.js开发的项目来说，Azure Pipeline可以执行以下操作：

trigger:
  - main

pool:
  vmImage: ubuntu-latest

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '20.x'

  - script: npm install

  - script: npm run lint

  - script: npm run test

  - script: npm run build

这个示例使用了Ubuntu作为构建代理。对于大多数使用TypeScript、Node.js、React或Tailwind CSS开发的项目来说，Ubuntu通常就已经足够了，因为这些应用程序并不依赖于特定的操作系统。

不过，团队也可以在多个操作系统上进行测试。如果需要这样做，只需将 imageName: ubuntu-latest替换为相应的操作系统名称即可。

例如：

strategy:
  matrix:
    linux:
      imageName: ubuntu-latest
    windows:
      imageName: windows-latest
    mac:
      imageName: macOS-latest

pool:
  vmImage: $(imageName)

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: '20.x'

  - script: npm install
  - script: npm run lint
  - script: npm run test
  - script: npm run build

当项目需要确保在Linux、Windows和macOS上构建和测试都能通过时，就可以使用这种方法。

对于普通的Web应用程序来说，使用Ubuntu就已经足够了。但对于桌面应用程序、命令行工具、跨平台软件包或与移动设备相关的开发项目而言，在多个操作系统上进行测试会更为合适。

这种构建流程能够确保依赖关系被正确安装，代码质量检查通过，测试结果合格，并且生产环境的构建也能成功完成。所有这些步骤都必须在拉取请求被合并之前完成。

由于这个构建流程会自动执行各种质量控制措施，因此开发人员就不再需要为代码质量问题而争论了。

使用基于角色的访问控制机制，而非单独设置用户权限

当团队规模扩大后，手动管理每个用户的权限就会变得非常繁琐。想象一下，如果要为500名开发人员分别配置权限，那将会是一件多么复杂的事情。

因此，更好的方法是创建一些组，然后根据需要将这些组与Azure DevOps中的角色对应起来。

例如：

前端开发人员
后端开发人员
DevOps工程师
质量保障团队
项目管理员

接着，将这些组与相应的Azure DevOps角色进行关联：

前端开发人员 → 贡献者
质量保障团队 → 读取者
DevOps工程师 → 管理员

这样就能确保权限管理的一致性，同时大大降低行政管理工作量。

当有开发人员加入或离开团队时，管理员只需要更新其所属的组即可，而仓库的权限设置并不会因此发生改变。

从项目启动的第一天起，就自动完成仓库配置工作

随着组织规模的扩大，仓库的创建往往会被忽视，但却会成为技术债务的一个来源。

在小型团队中，手动创建仓库可能看起来并不会带来什么问题。开发人员可以通过Azure DevOps门户创建新的仓库，添加README文件，配置构建流程，然后开始开发新功能。

当这个过程在多个团队中被重复数百次时，问题就出现了。

有的代码库包含README文件，而有的则没有。

有些代码库设置了分支保护规则，而有些则允许直接将代码提交到生产环境。

有些代码库配备了CI/CD流水线，而有些则需要手动进行部署。

随着时间的推移，每个代码库都会变得不一样。这种不一致性会导致运营上的麻烦、安全风险以及新成员上手时的困难。

解决办法是将创建代码库的过程自动化，而不是让开发人员手动完成这些操作。

组织应该制定一个代码库模板，这样在创建新的代码库时，系统就能自动按照预定义的标准和配置来进行设置。

新创建的代码库应该自动包含以下文件：

README.md
CONTRIBUTING.md
CODEOWNERS
.gitignore
azure-pipelines.yml
docs/
src/
tests/

这样就能确保每个项目都从相同的基础开始发展。

目标很简单：

每个代码库在创建出来的那一刻就应该具备生产环境所需的所有条件。

为什么代码库模板很重要

假设你的组织有150个代码库，如果没有自动化工具，那么每个代码库的负责人都必须记住以下这些步骤：

• 编写文档

• 配置分支管理规则

• 搭建构建流水线

• 设置权限

• 添加安全检查机制

• 规划文件夹结构

这样一来，出现不一致性的可能性就会大大增加。

而使用代码库模板的话，每个新创建的代码库都会自动继承组织设定的标准配置。

例如，一个用于Node.js和TypeScript项目的代码库模板可能如下所示：

customer-auth-service/
│
├── src/
│
├── tests/
│
├── docs/
│
├── README.md
│
├── CONTRIBUTING.md
│
├── .gitignore
│
├── package.json
│
├── tsconfig.json
│
└── azure-pipelines.yml

开发人员可以立即开始工作，而无需花费时间去配置项目的基础设施。

使用Terraform自动化代码库的创建过程

最常见的方法之一就是使用Terraform来配置Azure DevOps相关的资源。

团队们不再通过Azure DevOps的控制面板手动创建代码库，而是利用“基础设施即代码”的理念来进行代码库的配置。

举个例子：

resource "azuredevops_project" "platform" {
    name = "Customer Platform" 
} 

resource "azuredevops-git_repository" "auth_service" {         project_id = azuredevops_project.platform.id 

    name = "customer-auth-service" 
    
    initialization { 
        init_type = "Clean" 
    } 
    }

让我们来详细分析一下这个过程。

第一个操作会创建一个名为“Customer Platform”的Azure DevOps项目。

第二个操作会自动创建一个名为customer-auth-service的Git仓库。执行以下命令即可：

terraform apply

这样就可以创建仓库，而无需任何人使用Azure DevOps界面进行操作。

当需要管理数十甚至数百个仓库时，这种方法会显得格外有用。

通过Azure DevOps REST API创建仓库

Terraform非常适合基础设施团队使用。但有些组织更倾向于使用内部的自动化工具。

Azure DevOps提供了REST API，允许通过编程方式创建仓库。

示例：

curl -X POST \
https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=7.1 \
-H "Content-Type: application/json" \
-H "Authorization: Bearer " \
-d '{
  "name": "customer-auth-service"
}'

通过这个请求，就可以在Azure DevOps中自动创建仓库。

许多组织会建立内部门户，让开发人员在这些门户上填写相关信息：

仓库名称：customer-auth-service  
项目名称：Customer Platform  
编程语言：TypeScript  
模板类型：Node.js API

之后，该平台会在后台调用Azure DevOps的API，自动完成所有配置工作。

自动创建CI/CD管道

仓库的创建过程不应该仅仅停留在源代码控制这一阶段。没有自动化机制的仓库是不完整的。

对于使用TypeScript和Node.js开发的服务来说，可以自动配置Azure Pipeline模板：

触发条件：

• main

pool: vmImage: ubuntu-latest

执行步骤：

• task: NodeTool@0 inputs: versionSpec: ’20.x’

• script: npm install

• script: npm run lint

• script: npm run test

• script: npm run build

这个管道会自动安装Node.js及其依赖项，执行代码检查，运行测试，并构建应用程序。

每个新创建的仓库都会遵循相同的CI/CD标准，无需进行任何手动配置。

自动应用分支策略

仓库自动化还应该包括治理机制。

在仓库创建完成后，可以立即通过自动化手段配置以下内容：

• 拉取请求的要求

• 审核者的权限设置

• 构建验证规则

• 合并限制策略

例如：

main branch 
│ 
├── 需要2名审核者参与审查  
├── 构建必须成功才能提交  
├── 需要与相关任务关联  
└── 禁止直接提交代码

通过自动化机制，可以确保每个仓库从一开始就遵循组织制定的政策要求，而无需依赖开发人员去记住这些设置。

示例：自动化新TypeScript服务的配置过程

假设有一位开发人员请求创建一个名为“customer-notification-service”的新服务：

customer-notification-service

通过自动化流程，可以完成以下操作：

1. 创建代码仓库。

2. 添加README.md文件。

3. 设置TypeScript项目结构。

4. 配置Azure Pipeline流程。

5. 应用分支保护规则。

6. 指定负责团队。

7. 设置安全权限。

8. 注册监控与部署管道。

几分钟内，代码仓库就能准备好用于开发。无需进行任何手动配置，也不会出现配置错误或标准不一致的问题。

将代码仓库的创建过程视为产品制造

将代码仓库的配置过程比作产品制造，是一种很有帮助的思考方式。工厂并不会从零开始制造每一辆汽车，而是会遵循一套可重复执行的流程。

代码仓库的创建也应该遵循同样的原则。

每一个代码仓库在生成时都应该具备以下要素：

• 标准化的结构

• 安全控制机制

• CI/CD部署流程

• 文档资料

• 管理政策

自动化配置能够确保第100个代码仓库与第一个代码仓库具有完全相同的配置标准。

随着组织规模的扩大，这种一致性就成为了维护代码仓库质量、降低运营成本、并让开发团队能够更快地推进工作而不影响管理效率的关键因素。

在性能下降之前监测代码仓库的健康状况

通常情况下，人们直到开发人员开始抱怨才会注意到代码仓库的健康问题。而到那时，代码仓库往往已经出现了严重的臃肿现象。

Azure Repos提供了多种工具来帮助检测代码仓库的异常情况，例如：

• 庞大的代码仓库

• 体积巨大的文件

• 过量的提交操作

• 存储空间的快速增长

定期进行监测可以在性能问题影响到开发人员之前及时发现并解决它们。

控制代码仓库的大小

Azure Repos支持最大容量为250 GB的代码仓库。但这并不意味着代码仓库的实际大小就应该接近这个上限——通常在达到这个规模之前，性能就已经开始下降了。因此，要特别注意那些体积庞大的二进制文件、大型媒体资源、生成的临时文件以及构建产物。

绝对不要将以下类型的文件存储在代码仓库中：

.zip
.rar
.iso
.exe
.mp4
.psd

相反，应该使用Azure Blob Storage、包管理工具、Git LFS或Azure Artifacts来存储这些文件。

代码仓库的本质应该是用来存储源代码的，仅此而已！

使用 Git LFS来处理大型文件/资源

有时候，大型文件是不可避免的。

通常情况下，一个普通的Web应用不应该将体积较大的文件存储在Git仓库中。但有些项目确实需要这样做。例如，一个设计系统可能会包含Photoshop文件；一个媒体平台可能需要保存示例视频；而一个游戏项目则可能涉及纹理、音频以及3D资源文件。

问题在于，Git最初是为处理源代码而设计的，并非为存储大型二进制文件而设计的。当你直接将一个大型文件提交到Git仓库中时，这个文件就会成为仓库历史记录的一部分。即使后来你删除了这个文件，它的旧版本仍然会保留在历史记录中，除非你重新编写这些文件的内容。

正因如此，随着时间的推移，仓库的运行速度会变慢，体积也会逐渐增大。

Git LFS（即Git大型文件存储功能）通过将大型文件存储在常规Git历史记录之外，解决了这个问题。你的仓库只会保留一个小的指针文件，而实际的大型文件则会被单独保存起来。

git lfs install
git lfs track "*.psd"
git lfs track "*.fig"
git lfs track "*.mp4"
git lfs track "*.zip"
git add .gitattributes
git commit -m "配置Git LFS"

`.gitattributes`文件的内容如下：

*.psd filter=lfs diff=lfs merge=lfs -text
*.fig filter=lfs diff=lfs merge=lfs -text
*.mp4 filter=lfs diff=lfs merge=lfs -text
*.zip filter=lfs diff=lfs merge=lfs -text

这段代码告诉Git：“每当有这些类型的文件被添加到仓库中时，应该使用Git LFS来存储它们，而不是将其纳入常规的Git历史记录中。”

git add assets/design/homepage.psd
git commit -m "添加首页设计源文件"
git push

现在，这个大型`.psd`文件就已经由Git LFS来处理了。

为新仓库自动配置Git LFS

在大规模的应用环境中，你不能指望每个开发人员都能手动记住这些命令。因此，你应该编写一个脚本，在新仓库创建时自动执行这些配置操作。