Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022
使用业务结构作为在 Azure DevOps 中创建的组织、项目和团队数量的指南。 此全面的规划指南可帮助你设计与业务目标保持一致开发工作流的最佳组织结构。
战略规划框架
主要结构决策
解决以下基本问题，指导 Azure DevOps 结构：
组织级别：
- 你需要多少个组织？ - 考虑安全性、合规性和业务部门分离
- 如何将组织映射到业务部门 - 符合企业结构和治理需求
项目级别：
团队和存储库级别：
支持性考虑因素
- 访问管理：定义谁需要访问哪些信息和资源
- 报告要求：规划跨团队可见性和项目组合管理
- 流程标准化：促进一致的做法，同时允许团队灵活性
- 文化一致性：培养 敏捷思维模式和协作文化
提示
从更简单的结构开始，随着组织的发展而发展。 拆分大型项目比合并单独的组织更容易。
了解 Azure DevOps 组织
Azure DevOps 中的组织充当项目的顶级容器，提供计费、安全性和管理边界。 组织使你能够：
- 跨相关项目和团队集中计费和许可
- 使用不同的访问控制和策略建立安全边界
- 为不同的业务部门或合规性要求提供管理隔离
- 连接到身份提供者，例如 Microsoft Entra ID 以实现统一身份验证
组织权益和免费层
每个组织包括最多五个用户的免费层服务：
| 服务 | 免费层福利 |
|---|---|
| Azure Pipelines | 一个托管作业，每月为 CI/CD 提供 1,800 分钟，再加上一个自托管作业。 |
| Azure 板 | 用于项目管理的工作项跟踪和看板板 |
| 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 中的云负载测试。
常见组织模式：
- 单一组织：大多数公司都受益于一个组织进行统一协作
- 业务部门组织：针对不同的合规性或安全要求将组织分开
- 地理组织：数据驻留或本地治理的区域分离
你需要多少个组织？
从一个组织开始 ，仅在具有需要分离的特定业务需求时才进行扩展。
多个组织的决策条件
在需要时创建更多组织：
安全性和合规性分离：
- 不同的法规要求（SOX、HIPAA、PCI-DSS）
- 不同的客户数据隔离要求
- 单独的审计跟踪和合规性报告
业务结构要求：
- 具有独立 IT 治理的独立业务部门
- 不同的计费和成本中心要求
- 不同的身份提供商连接（不同的 Microsoft Entra 租户）
管理边界：
- 不重叠的不同管理员组
- 单独的组织策略和控制
- 独立服务级别协议
评估框架
| 因子 | 单个组织 | 多个组织 |
|---|---|---|
| 协作 | 最大可见性和共享 | 隔离的、受限的跨组织共享 |
| 管理 | 集中、更简单的管理 | 分布式系统，行政管理开销更多 |
| 报告 | 统一仪表板和分析 | 单独的报告系统 |
| Cost | 单个计费实体 | 多个计费实体 |
| Security | 共享边界，统一策略 | 硬边界，独立策略 |
重要
对于公司拥有的 Microsoft Entra 组织，请考虑 限制组织创建 以保护知识产权和维护治理。
什么是团队？
团队是支持许多 团队可配置工具的单元。 这些工具可帮助你规划和管理工作，并简化协作。
为每个不同的产品或功能团队创建团队
每个团队都有自己的积压工作。 若要创建新的积压工作，请创建新的团队。 将团队和积压工作配置为分层结构，以便计划所有者可以更轻松地跨团队跟踪进度、管理项目组合和生成汇总数据。 创建团队时会创建团队组。 可以在查询中使用此组，或设置团队的权限。
了解项目
项目为开发工作提供容器，其中包含以下集成服务：
- Azure Boards：使用积压工作、冲刺和工作项跟踪进行敏捷规划
- Azure Pipelines：持续集成和部署自动化
- Azure Repos：用于源代码管理的 Git 或 TFVC 存储库
- Azure 测试计划：手动和自动测试集成
- 共享资源：Wiki、仪表板和项目级设置
在以下示例中，Contoso Manufacturing 使用四个项目来组织不同的生产线：
项目优势和注意事项
项目启用：
- 跨团队共享迭代计划和分类
- 一致的进程模板和工作项类型
- 集成报告和项目组合管理
- 简化的用户管理和访问控制
项目设置了以下边界：
- 安全性和访问权限
- 流程自定义和工作跟踪
- 管理策略和治理
- 资源分配和计费跟踪
需要多少个项目？
至少有一个项目开始使用 Azure DevOps 服务，例如 Azure Boards、Azure Repos 或 Azure Pipelines。 创建组织时，会为你创建一个默认项目。 在默认项目中，有一个代码存储库开始工作、积压工作跟踪工作，以及至少一个管道开始自动生成和发布。
在组织中，可以执行以下任一方法：
- 创建包含多个存储库和团队的单个项目
- 创建许多项目，每个项目都有自己的团队、存储库、生成、工作项和其他元素集
即使有许多团队处理数百个不同的应用程序和软件项目，也可以在 Azure DevOps 中的单个项目中管理它们。 但是，如果要管理软件项目与其团队之间的更精细的安全性，请考虑使用许多项目。 在最高级别的隔离级别是一个组织，其中每个组织都连接到单个Microsoft Entra 租户。 但是，单个Microsoft Entra 租户可以连接到许多 Azure DevOps 组织。
注意
如果为组织启用了“ 将用户可见性和协作限制为特定项目 预览”功能，则添加到 Project-Scoped 用户组 的用户无法访问他们未添加到的项目。 有关详细信息和重要的安全相关标注，请参阅 管理组织、限制项目的用户可见性等。
项目决策框架
根据协作需求选择适当的项目结构：
单个项目方法：
- 最适合：具有紧密协作的小型组织或团队
- 优点：最大可见性、共享资源、统一报告
- 考虑何时：团队在类似的发布周期内开发相关产品
多个项目方法：
- 最适合：具有不同要求的独立团队
- 优点：更好的安全边界、可自定义流程、团队自主性
- 考虑何时：不同的合规性需求或单独的业务部门
Azure DevOps 提供跨项目体验，用于跨多个项目管理工作。
请考虑多个项目：
- 限制或管理对特定信息的访问权限
- 支持不同业务部门的自定义工作跟踪流程
- 支持具有独立管理策略的独立业务部门
- 在生产环境上线之前测试自定义或扩展
重要
Git 存储库可移植性允许在项目之间轻松迁移存储库（包括完整历史记录）。 但是，诸如推送和合并请求的其他历史记录不能在项目之间迁移。
将项目映射到业务部门时，你的公司获得单个组织，并设置多个项目，其中包含一个或多个表示业务部门的项目。 公司的所有 Azure DevOps 资产都包含在此组织内，并位于给定地理位置（例如欧洲）。 将项目映射到业务部门时，请注意以下指导：
| 一个项目、多个团队 | 一个组织、多个项目和团队 | 多个组织 | |
|---|---|---|---|
| 一般指南 | 最适合小型组织或具有高度一致团队的大型组织。 | 适合不同的工作需要不同的流程。 | 用作遗留系统迁移的一部分以及组织之间严格的安全边界。 与每个组织内的多个项目和团队一起使用。 |
| 缩放 | 支持数万个用户和数百个团队，但如果所有团队都在进行相关工作，则最好在此规模上。 | 与一个项目相同，但许多项目可能更容易。 | |
| 处理 | 跨团队协调流程；团队可以灵活地自定义板、仪表板等。 | 每个项目的独立流程。 例如，不同的工作项类型、自定义字段等。 | 与多个项目相同。 |
| 协作 | 不同团队的工作和资产之间的最高默认可见性和重用。 | 良好的可见性和重用是可能的，但无论是否有意，在项目之间隐藏资产都更容易。 | 组织之间较差的可见性、协作和重用。 |
| 汇总报告和项目组合管理 | 跨团队汇总以及在团队之间协调的最佳能力。 | 可以很好地跨项目报告。 更难以跨项目汇总和团队协调。 | 组织之间没有汇总或协调。 |
| 安全性/隔离 | 可以在团队级别锁定资产，但默认为开放可见性和协作。 | 更好地在项目之间锁定的功能。 默认情况下，在项目中提供良好的可见性并跨项目进行良好的隔离。 | 跨组织的硬边界；出色的隔离和跨组织共享的最小能力。 |
| 上下文切换 | 最便于团队协作和用户切换工作。 | 用户比较容易协同工作，并在工作之间切换上下文。 | 用户更加难以跨不同组织工作。 |
| 信息重载 | 默认情况下，使用“收藏夹”和类似机制以避免“信息重载”的用户可以看到所有资产。 | 降低信息重载的风险；跨项目边界隐藏的大多数项目资产。 | 跨组织的资产已隔离，降低了信息重载的风险。 |
| 管理开销 | 许多管理委托给单个团队。 更便于用户许可和组织级别管理。 如果需要在工作之间进行协调，则可能需要执行更多工作。 | 在项目级别进行更多管理。 开销更大，但当项目有不同的管理需求时，可能会很有用。 | 项目越多，管理开销就越多，这在组织之间实现了更大的灵活性。 |
在项目中结构存储库和版本控制
请考虑特定于之前创建的组织之一以及需要访问权限的组织之一的具体战略工作。 使用此信息命名和 创建项目。 此项目具有在在其中创建它的组织下定义的 URL，可在 访问 https://dev.azure.com/{organization-name}/{project-name}.
在 Project 设置中配置项目。
有关管理项目的详细信息，请参阅 Azure DevOps 中的“管理项目”。 可以通过迁移数据将项目移动到其他组织。 有关迁移项目的详细信息，请参阅 迁移概述。
存储库策略和版本控制
根据团队大小、产品体系结构和部署要求配置存储库策略。
版本控制系统选择
在 Git 和 Team Foundation 版本控制（TFVC）之间进行选择：
Git 存储库：
- 现代开发工作流的推荐方法
- 每个项目无限制的存储库
- 具有灵活分支的分布式版本控制
- 与大多数开发工具和 CI/CD 系统集成
Team Foundation 版本控制（TFVC）：
- 集中式版本控制系统
- 每个项目使用单一存储库，并进行基于文件夹的组织
- 适用于喜欢集中工作流的团队
提示
如果团队具有不同的工作流首选项，则项目可以使用 Git 和 TFVC 存储库。
存储库组织模式
Monorepo 策略：
- 最适合：小型团队通过相关服务提升发展速度
- 优点：简化共享和协调的更改
- 挑战：随着团队的增长，知识复杂性增加;意外的服务耦合;难以更改跟踪
单独的存储库策略：
- 最适合：具有独立服务部署的大型团队
- 优点：清除服务边界、简化载入、独立发布周期
- 注意事项：需要更多初始设置，但随着团队增长能够有效扩展
提示
从小型团队的单存储库开始，随着组织的增长和复杂性的增加，过渡到单独的存储库。
存储库和项目对齐策略
具有多个存储库的单个项目：
- 最适合：具有协调发布计划的产品/服务
- 优点：共享流程、一致的访问控制、简化的管理
- 使用场景：开发人员经常跨多个代码库工作，需要一致的工具。
具有专用存储库的多个项目：
- 最适合：具有独立计划或不同要求的产品
- 优点：独立自定义、独立治理、明确边界
注意
Git 存储库可移植性允许在具有完整提交历史记录的项目之间轻松迁移。
存储库组织的决策因素：
- 代码依赖项：将独立可部署的产品/服务放置在单独的存储库中
- 协调需求：预期协调更改时将相关代码库保持一起
- 体系结构：在单个存储库中维护现有单体架构；分离不相连的服务
- 团队访问权限：实施适当的 权限管理 来控制存储库创建
共享存储库与分支存储库
建议在受信任的组织中使用共享存储库。 开发人员使用分支来保持彼此更改的隔离。 通过良好的分支和发布策略，单个存储库可以缩放以支持一千多个开发人员的并发开发。 有关分支和发布策略的详细信息，请参阅 采用 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
组织属于同一家公司，但大多彼此隔离。 无需以这种方式分隔任何内容。 只有在业务有意义时才能创建边界。
提示
可以更轻松地将现有组织与项目分区，而不是合并不同的组织。