计划组织结构

项目
11/19/2024

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

使用业务结构作为在 Azure DevOps 中创建的组织、项目和团队数量的指南。本文可帮助你规划 Azure DevOps 的不同结构和方案。

请考虑以下 Azure DevOps 中业务和协作工作的结构：

组织数
组织下的项目数

可能还需要规划以下方案：

将 Azure DevOps 中的组织和项目映射到企业、业务部门和团队结构
构建存储库（存储库）
构建团队 - 它可以帮助或阻碍团队成为敏捷和自治团队
管理对数据的访问 - 谁需要访问，谁没有访问权限？
报告需求
推广常见做法 - 使用基础元素创建敏捷思维模式和文化

至少有一个组织，可以代表你的公司、更大的代码项目集合，甚至多个相关的业务部门。

什么是组织？

Azure DevOps 中的组织是一种用于组织和连接相关项目组的机制。示例包括业务部门、区域部门或其他企业结构。可以为整个公司选择一个组织，为自己选择一个组织，也可以为特定业务部门选择单独的组织。

每个组织将获得其自己的 免费层 服务（每个服务类型最多五个用户），如下所示。可以使用所有服务，或仅选择补充现有工作流所需的服务。

Azure Pipelines：一个托管作业，每月 1,800 分钟用于 CI/CD 和一个自承载作业
Azure Boards：工作项跟踪和板
Azure Repos：无限制的专用 Git 存储库
Azure Artifacts：包管理
无限制利益干系人
- 前 5 个用户免费 (基本许可证)
- Azure Pipelines
  - 一个 Microsoft 托管的 CI/CD (一个并发作业，每月最多 30 小时)
  - 一个自承载 CI/CD 并发作业
- Azure Boards： 工作项跟踪和板
- Azure Repos：无限制的专用 Git 存储库
- Azure Artifacts： 每个组织两个免费 GiB

注意

Azure DevOps 基于云的负载测试服务已弃用，但 Azure 负载测试 仍可用。使用此完全托管的负载测试服务，可以使用现有的 Apache JMeter 脚本生成大规模负载。有关详细信息，请参阅什么是 Azure 负载测试？以及 Visual Studio 中的负载测试功能的更改，以及 Azure DevOps 中的云负载测试。

你需要多少个组织？

从 Azure DevOps 中的一个组织开始。然后，可以添加更多组织（以后可能需要不同的安全模型）。单个代码存储库或项目只需要一个组织。如果你有单独的团队需要以隔离方式处理代码或其他项目，请考虑为这些团队创建单独的组织。它们将有不同的 URL。在添加另一个组织之前，根据需要添加项目、团队和存储库。

花些时间查看工作结构和要管理的不同业务组和参与者。有关详细信息，请参阅将项目映射到业务部门和结构注意事项。

提示

对于公司拥有Microsoft Entra 组织，请考虑限制用户创建新组织作为保护 IP 的方式。有关详细信息，请参阅通过 Microsoft Entra 租户策略限制组织创建。用户可以使用其 MSA 或 GitHub 帐户创建组织，但没有任何限制。

什么是团队？

团队是支持许多团队可配置工具的单元。这些工具可帮助你规划和管理工作，并简化协作。

为每个不同的产品或功能团队创建团队

每个团队都有自己的积压工作。若要创建新的积压工作，请创建新的团队。将团队和积压工作配置为分层结构，以便计划所有者可以更轻松地跨团队跟踪进度、管理项目组合和生成汇总数据。创建团队时会创建团队组。可以在查询中使用此组，或设置团队的权限。

什么是项目？

Azure DevOps 中的项目包含以下一组功能：

敏捷规划的板和积压工作
用于持续集成和部署的管道
存储库，用于源代码和项目的版本控制和管理
整个项目生命周期内的持续测试集成每个组织都包含一个或多个项目

下图中，虚构的 Contoso 公司在其 Contoso-Manufacturing 组织中拥有四个项目。

包含四个项目的组织的图像

需要多少个项目？

至少有一个项目开始使用 Azure DevOps 服务，例如 Azure Boards、Azure Repos 或 Azure Pipelines。创建组织时，会为你创建一个默认项目。在默认项目中，有一个代码存储库开始工作、积压工作跟踪工作，以及至少一个管道开始自动生成和发布。

在组织中，可以执行以下任一方法：

创建包含多个存储库和团队的单个项目
创建许多项目，每个项目都有自己的团队、存储库、生成、工作项和其他元素集

即使有许多团队处理数百个不同的应用程序和软件项目，也可以在 Azure DevOps 中的单个项目中管理它们。但是，如果要管理软件项目与其团队之间的更精细的安全性，请考虑使用许多项目。在最高级别的隔离级别是一个组织，其中每个组织都连接到单个Microsoft Entra 租户。但是，单个Microsoft Entra 租户可以连接到许多 Azure DevOps 组织。

注意

如果为组织启用了 “将用户可见性和协作限制为特定项目 ”预览功能，则添加到 “项目范围用户” 组的用户将无法访问他们尚未添加到的项目。有关详细信息和重要的安全相关标注，请参阅管理组织、限制项目的用户可见性等。

单个项目

单个项目将整个组织的所有工作置于同一“项目组合”级别。你的工作具有相同的存储库和迭代路径集。使用单个项目，团队可以共享源存储库、生成定义、发布定义、报表和包源。你可能拥有由许多团队管理的大型产品或服务。这些团队在整个产品生命周期中具有紧密的相互依赖关系。创建项目并使用团队和区域路径划分工作。此设置使团队能够了解彼此的工作，使组织保持一致。你的团队对工作项跟踪使用相同的分类，使沟通和保持一致变得更加容易。

提示

当多个团队处理同一产品时，让所有团队在同一迭代计划上有助于保持团队保持一致并按相同节奏交付价值。例如，Azure DevOps 中的组织在单个项目中有超过 40 个功能团队和 500 个用户，这很有效，因为我们都在处理具有常见目标和常见发布计划的通用产品集。

大量的查询和版块使得很难找到要查找的内容。根据产品的体系结构，这种困难可能会出血到其他领域，例如生成、发布和存储库。请确保使用良好的命名约定和简单的文件夹结构。向项目添加存储库时，请考虑你的策略并确定该存储库是否可以放入其自己的项目中。

许多项目

通过交付产品的方式，可以最好地确定项目结构。拥有多个项目会转移管理负担，并让团队在做决定时有更多的自主权来管理项目。它还可以更好地控制不同项目中的安全性和对资产的访问。但是，许多项目具有团队独立性会产生一些对齐挑战。如果每个项目使用不同的流程或迭代计划，则在分类不相同时可能会使通信和协作变得困难。

提示

如果在所有项目中使用相同的流程和迭代计划，则可以在整个团队中汇总数据和报表。

Azure DevOps 提供用于管理工作的跨项目体验。

由于以下情况，可能需要添加另一个项目：

禁止或管理对项目中信息的访问权限
支持组织中特定业务部门的自定义工作跟踪流程
支持完全独立的业务部门，这些业务部门有自己的管理策略和管理员
支持在对工作项目推出更改之前测试自定义活动或添加扩展

在考虑许多项目时，请记住，Git 存储库可移植性可以轻松地在项目之间迁移存储库（包括完整历史记录）。无法在项目之间迁移其他历史记录。示例包括推送和拉取请求历史记录。

将项目映射到业务部门时，你的公司获得单个组织，并设置多个项目，其中包含一个或多个表示业务部门的项目。公司的所有 Azure DevOps 资产都包含在此组织中，位于给定区域（例如，西欧）。将项目映射到业务部门时，请注意以下指导：

	一个项目、多个团队	一个组织、多个项目和团队	多个组织
一般指南	最适合小型组织或具有高度一致团队的大型组织。	适合不同的工作需要不同的流程。	可用作 TFS 旧版迁移的一部分，并且可用于组织之间的硬安全边界。与每个组织内的多个项目和团队一起使用。
缩放	支持数万个用户和数百个团队，但如果所有团队都在进行相关工作，则最好在此规模上。	与一个项目相同，但多个项目可能更简单。
处理	跨团队协调流程；团队可以灵活地自定义板、仪表板等。	每个项目的独立流程。例如，不同的工作项类型、自定义字段等。	与多个项目相同。
协作	不同团队的工作和资产之间的最高默认可见性和重用。	良好的可见性和重用是可能的，但无论是否有意，在项目之间隐藏资产都更容易。	组织之间较差的可见性、协作和重用。
汇总报告和项目组合管理	跨团队汇总以及在团队之间协调的最佳能力。	可以很好地跨项目报告。更难以跨项目汇总和团队协调。	组织之间没有汇总或协调。
安全性/隔离	可以在团队级别锁定资产，但默认为开放可见性和协作。	更好地在项目之间锁定的功能。默认情况下，在项目中提供良好的可见性并跨项目进行良好的隔离。	跨组织的硬边界；出色的隔离和跨组织共享的最小能力。
上下文切换	最便于团队协作和用户切换工作。	用户比较容易协同工作，并在工作之间切换上下文。	用户更加难以跨不同组织工作。
信息重载	默认情况下，使用“收藏夹”和类似机制来避免“信息重载”的用户可以看到所有资产。	降低信息重载的风险；跨项目边界隐藏的大多数项目资产。	跨组织的资产已隔离，降低了信息重载的风险。
管理开销	许多管理委托给单个团队。更便于用户许可和组织级别管理。如果需要在工作之间进行协调，则可能需要执行更多工作。	在项目级别进行更多管理。开销更大，但当项目有不同的管理需求时，可能会很有用。	项目越多，管理开销就越多，这在组织之间实现了更大的灵活性。

在项目中结构存储库和版本控制

请考虑特定于之前创建的组织之一以及需要访问权限的组织之一的具体战略工作。使用此信息命名和创建项目。此项目具有在在其中创建它的组织下定义的 URL，可在访问 https://dev.azure.com/{organization-name}/{project-name}.

在 Project 设置中配置项目。

显示“项目设置”按钮的屏幕截图。

有关管理项目的详细信息，请参阅 Azure DevOps 中的“管理项目”。可以通过迁移数据将项目移动到其他组织。有关迁移项目的详细信息，请参阅迁移概述。

管理版本控制

在启用了 Azure Repos 服务的项目中，版本控制存储库可以存储和修改代码。配置存储库时，请考虑以下选项。

Git 与Team Foundation 版本控制（TFVC）

Azure Repos 提供以下版本控制系统供团队选择：

Git 和 TFVC。项目可以具有每种类型的存储库。默认情况下，新项目有一个空的 Git 存储库。 Git 可以在开发人员工作流中实现极大的灵活性，并与开发人员生态系统中几乎每个相关工具集成。任何项目都可以使用 Git 存储库。可以添加到项目中的 Git 存储库数量没有限制。

TFVC 是一种集中式版本控制系统，也可用。与 Git 不同，一个项目只允许使用一个 TFVC 存储库。但是，如果需要，在该存储库中，文件夹和分支用于组织多个产品和服务的代码。如果适用，项目可以使用 TFVC 和 Git。

Monorepo 与每个服务一个存储库

从 monorepo 部署各种独立服务对于旨在建立早期势头的小团队来说，可以有效。但是，由于以下几个因素，团队的增长，此策略可能会变得有问题：

新成员所需的知识随着系统的整体复杂性而增加。
单个存储库中的代码共享可能会导致服务之间意外耦合。
共享代码中的更改可能会影响各种服务的行为，从而难以跟踪这些更改。

对于大型团队，管理单一存储库需要强大的工程学科和可靠的工具。或者，可以选择每个服务的单个存储库，以及共享资源的单独存储库。尽管此方法涉及更多的初始设置，但随着团队的增长，此方法会更有效地进行缩放。它还使新成员的加入更容易，他们只能专注于其特定的服务存储库。

如果你从一个小团队开始，单一存储库可能是一个不错的选择。随着团队的扩展和复杂性的增加，你可以过渡到单独的存储库。

项目中的一个存储库与多个存储库

是否需要在单个项目中设置多个存储库，还是为每个项目设置存储库？以下指南与这些存储库中的规划和管理功能相关。

如果产品/服务按协调的发布计划工作，则包含多个存储库的一个项目非常有效。如果开发人员经常使用多个存储库，请将其保存在单个项目中，以确保流程保持共享且一致。在单个项目中管理存储库访问更容易，因为访问控制和选项（如案例强制和最大文件大小）在项目级别设置。即使存储库位于单个项目中，也可以单独管理访问控制和设置。

如果存储在多个存储库中的产品按独立的计划或流程工作，则可以将其拆分为多个项目。借助 Git 存储库可移植性，可以轻松地在项目之间移动存储库，并保持完全保真提交历史记录。不会轻易迁移其他历史记录，例如拉取请求或生成历史记录。

根据以下因素和提示确定一个和多个存储库：

代码依赖项和体系结构
将每个独立部署的产品或服务置于其自己的存储库中
如果希望跨这些存储库进行协调的代码更改，请不要将代码库分隔成多个存储库，因为没有工具可以帮助协调这些更改
如果代码库已是整体式，请将其保存在一个存储库中。有关整体存储库的详细信息，请参阅如何使用 DevOps 文章Microsoft开发新式软件
如果有多个断开连接的服务，则每个服务有一个存储库是一个很好的策略

提示

请考虑管理权限，这样组织中的每个人都无法创建存储库。如果存储库过多，则很难跟踪谁拥有存储在这些存储库中的代码或其他内容。

共享存储库与分支存储库

建议在受信任的组织中使用共享存储库。开发人员使用分支来保持彼此更改的隔离。通过良好的分支和发布策略，单个存储库可以缩放以支持一千多个开发人员的并发开发。有关分支和发布策略的详细信息，请参阅采用 Git 分支策略和发布流：分支策略。

当你与不应具有直接访问权限的供应商团队合作来更新主存储库时，分支非常有用。在许多开发人员不经常参与的情况下（例如在开源项目中），分支也很有用。使用分支时，可能需要维护一个单独的项目，以将分支存储库与主存储库隔离开来。可能会增加管理开销，但可使主项目更简洁。有关详细信息，请参阅分支文章。

下图显示了“你的公司”如何构建其组织、项目、工作项、团队和存储库的示例。

显示公司组织结构的关系图。

管理临时资源和共享资源

请考虑如何通过采用以下最佳做法有效地管理临时和共享资源：

临时环境： 临时环境是生存期较短的，用于测试、开发或过渡等任务。高效管理这些环境：
- 单独的存储库和管道： 每个临时环境及其关联的资源（例如 Azure Functions）都应有自己的存储库和管道。这种分离使你能够同时部署和回滚环境及其资源，从而更轻松地根据需要启动和丢弃它们。
- 示例： 专门为开发环境创建存储库和管道，包括 Azure Functions、存储帐户和其他服务等所有必要的资源。
共享资源： 共享资源通常在多个环境中长期使用。这些资源通常具有更长的启动时间和更高的成本。有效管理共享资源：
- 单独的存储库和管道：共享资源（如Azure SQL 数据库）应有自己的存储库和管道。这种分离可确保临时环境能够使用这些共享资源，使其部署更快、更具成本效益。
- 示例：为Azure SQL 数据库创建存储库和管道，多个临时环境可以使用该存储库和管道。
共享基础结构资源： 共享基础结构资源（例如虚拟私有云（VPC）和子网（也称为登陆区域）也应有自己的存储库和管道。此方法可确保基础结构一致地进行管理，并且可以在不同的环境中重复使用。
- 示例： 为你的VP和子网配置创建存储库和管道，该配置可由其他存储库和管道引用。

有关组织结构的详细信息

选择组织管理员帐户类型

创建组织时，使用登录的凭据定义组织使用的标识提供者。使用Microsoft帐户或Microsoft Entra 实例创建组织。使用这些凭据以管理员身份登录到新组织。https://dev.azure.com/{YourOrganization}

使用Microsoft帐户

如果不需要使用 Microsoft Entra ID 对组织的用户进行身份验证，请使用Microsoft帐户。所有用户都必须使用Microsoft帐户登录到组织。如果还没有 Microsoft 帐户，请创建 Microsoft 帐户。

输入密码并登录

如果没有Microsoft Entra 实例，请从Azure 门户免费创建一个，或使用Microsoft帐户创建组织。然后，可以将组织连接到 Microsoft Entra ID。

使用 Microsoft Entra 帐户

如果使用 Azure 或 Microsoft 365，则可能已有Microsoft Entra 帐户。如果你为使用 Microsoft Entra ID 来管理用户权限的公司工作，则可能具有Microsoft Entra 帐户。

如果没有 Microsoft Entra 帐户，请注册 Microsoft Entra ID 以自动将组织连接到 Microsoft Entra ID。所有用户都必须是该目录中的成员才能访问组织。若要从其他组织添加用户，请使用 Microsoft Entra B2B 协作。

Azure DevOps 通过 Microsoft Entra ID 对用户进行身份验证，以便只有属于该目录中成员的用户才有权访问组织。从该目录中删除用户时，他们无法再访问你的组织。只有特定的 Microsoft Entra 管理员管理目录中的用户，以便管理员控制谁访问组织。

有关管理用户的详细信息，请参阅 “管理用户”。

将组织映射到业务部门

公司中的每个业务部门在 Azure DevOps 中都有自己的组织，以及自己的Microsoft Entra 租户。可以根据团队或正在进行的工作在各个组织内根据需要设置项目。

对于大型公司，可以使用不同的用户帐户创建多个组织（最有可能Microsoft Entra 帐户）。考虑哪些组和用户共享策略和工作，并将其分组到特定组织中。

例如，虚构的 Fabrikam 公司创建了以下三个组织：

Fabrikam-Marketing
Fabrikam-Engineering
Fabrikam-Sales

每个组织都有一个单独的 URL，例如：

https://dev.azure.com/Fabrikam-Marketing
https://dev.azure.com/Fabrikam-Engineering
https://dev.azure.com/Fabrikam-Sales

组织属于同一家公司，但大多彼此隔离。无需以这种方式分隔任何内容。只有在业务有意义时才能创建边界。

提示

可以更轻松地将现有组织与项目分区，而不是合并不同的组织。

通过

计划组织结构

什么是组织？

你需要多少个组织？