计划组织结构

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

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

请考虑在Azure DevOps中为业务和协作工作构建以下结构:

你可能还想要规划以下方案:

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

什么是组织?

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

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

注意

虽然Azure DevOps基于云的负载测试服务已弃用,但 Azure 负载测试预览版可用。 Azure 负载测试预览版是一项完全托管的负载测试服务,可用于使用现有的 Apache JMeter 脚本生成大规模负载。 若要了解详细信息,请参阅什么是 Azure 负载测试预览版? 若要了解有关弃用Azure DevOps负载测试和其他服务的详细信息,备用服务请参阅Visual Studio中的负载测试功能更改,以及Azure DevOps中的云负载测试更改

你需要多少个组织?

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

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

提示

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

什么是团队?

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

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

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

什么是项目?

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

  • 敏捷规划的Boards和积压工作
  • 用于持续集成和部署的Pipelines
  • Repos源代码和项目的版本控制和管理
  • 整个项目生命周期中的持续测试集成每个组织都包含一个或多个项目

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

Image of an organization with four projects

需要多少个项目?

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

在组织中,可以执行以下任一方法:

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

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

注意

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

单个项目

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

提示

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

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

许多项目

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

提示

如果在所有项目中使用相同的过程和迭代计划,则可以跨团队汇总数据和报告改进。

Azure DevOps提供跨项目体验来管理工作。

由于以下方案,可能需要添加另一个项目:

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

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

将项目映射到业务部门时,公司将获取一个组织,并设置多个项目,其中一个或多个项目代表业务部门。 公司的所有Azure DevOps资产都包含在此组织中,位于给定区域 (,例如西欧) 。 请考虑以下指南,将项目映射到业务部门:

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

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

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

Project设置中配置项目。

Screenshot showing the Project settings button.

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

管理版本控制

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

Git 与 Team Foundation 版本控制 (TFVC)

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

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

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

一个存储库与多个存储库

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

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

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

根据以下因素和提示,根据一对多存储库做出决策:

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

提示

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

共享存储库与分叉存储库

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

在与不应直接访问更新主存储库的供应商团队合作时,分叉非常有用。 对于许多开发人员不经常参与(例如在开源项目中)的方案中,分叉也很有用。 使用分叉时,可能需要维护单独的项目,以便将分叉存储库与主存储库隔离开来。 可能会增加管理开销,但它使主项目更简洁。 有关详细信息,请参阅 分支文章

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

Diagram showing organizational structure for a company.

有关组织结构的详细信息

选择组织管理员帐户类型

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

使用 Microsoft 帐户

如果你不需要对具有Azure AD的组织的用户进行身份验证,请使用 Microsoft 帐户。 所有用户都必须使用 Microsoft 帐户登录到组织。 如果没有帐户, 请创建一个 Microsoft 帐户

Enter your password and sign in

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

使用 Azure AD 帐户

如果使用 Azure 或Microsoft 365,则可能已有Azure AD帐户。 如果你为使用Azure AD管理用户权限的公司工作,则可能拥有一个Azure AD帐户。

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

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

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

将组织映射到业务部门

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

对于大型公司,可以使用不同用户帐户创建多个组织, (最有可能Azure AD帐户) 。 考虑哪些组和用户共享策略和工作,并将其分组到特定组织中。

例如,虚构的 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

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

提示

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