从 Azure DevOps Server 迁移到 Azure DevOps Services 对于希望利用基于云的协作、可伸缩性和增强功能的组织来说是必不可少的一步 在本概述中，我们将探讨将有价值的数据从本地 Azure DevOps 服务器传输到基于云的 Azure DevOps 服务的选项。
无论选择哪种迁移选项，我们建议确定最重要的资产，例如源代码和工作项。 应考虑数据大小、组织复杂性，并确保在实际迁移之前有足够的时间来运行测试，以实现平稳成功的过渡。
迁移方法
根据采用 Azure DevOps Services 的具体动机，评估每种迁移方法的优缺点至关重要。 正确的策略取决于你的独特环境和需求。
| 选项 | 建议方案 | 限制 |
|---|---|---|
| 1：手动迁移 | 用于较小的项目或特定数据子集。 | 并非所有数据都可以以完全保真度进行迁移，并且会受到限制。 此迁移不支持迁移 XML 模板，因此你需要将流程模板重新创建为继承模板。 |
| 2：Azure DevOps 数据迁移工具 | 用于具有不同数据类型和复杂结构的中大规模迁移。 | 只能将一个 Azure DevOps Server 集合“直接迁移”到一个新的 Azure DevOps Services 组织，无需进行任何修改。 有关详细信息，请参阅“限制”部分。 |
| 3：基于 API 的迁移 | 为具有独特迁移要求或自动化需求的组织提供灵活性和自定义功能。 | 可能会出现低保真、数据丢失和 ID 更改。 有关详细信息，请参阅“限制”部分。 |
选项 1：手动迁移
例如，当 Microsoft 的 Azure DevOps 团队选择从 Azure DevOps Server 迁移到 Azure DevOps Services 时，我们也决定从 Team Foundation 版本控制 (TFVC) 迁移到 Git。 迁移需要大量的规划，但在迁移时，我们使用 TFVC 源的“提示”版本创建了一个新的 Git 存储库，并将我们的历史记录遗留在 Azure DevOps Server 中。 我们还移动了活动工作项，留下了所有旧 bug、已完成的用户故事和任务等。
手动迁移过程
- 确定需要迁移的最重要资产，通常是源代码、工作项或两者兼而有之。 Azure DevOps Server 中的其他资产（生成管道、测试计划等）更难手动迁移。
- 确定一个合适的时间进行转换。
- 准备目标组织。 创建所需的组织和团队项目、预配用户等。
- 迁移数据。
- 考虑将源 Azure DevOps Server 部署设置为只读。 你可通过以下方式完成此操作：
- 调整项目级权限：在项目级别将所有用户或组的权限设置为只读，可以通过修改“项目设置”中的安全角色来实现。
- 修改存储库设置：对于每个存储库，可以更改设置使其为只读，这涉及调整每个用户或组的权限，使其仅允许读取操作。
- 使用内置安全组：利用内置安全组更有效地管理权限。 可以将用户分配到“读取者”等组，以提供只读访问权限。
- 脚本权限更改：如果有多个项目或存储库，则可能需要为它们编写脚本。 可以使用 Azure CLI DevOps 扩展列出所有权限，并根据需要进行更新。
- 禁用存储库功能：禁止访问存储库（包括生成和拉取请求），但使其可被发现并发出警告。 转到项目设置>存储库>，进入存储库，然后在“禁用存储库”旁边，将开关移动到开启。
选项 2：Azure DevOps 数据迁移工具
Azure DevOps 数据迁移工具是 Microsoft 提供的一组实用工具，可帮助将数据从 Azure DevOps Server 迁移到 Azure DevOps Services。 这些工具提供了一种简化的方法来迁移各种工件，包括源代码、工作项、测试用例和其他与项目相关的数据。
在启动迁移过程之前，这些工具可以执行预迁移分析，以评估源环境的准备情况，并确定可能影响迁移的潜在问题或依赖关系。 评估准备情况，以便你可以提前计划和缓解潜在的挑战。
迁移工具限制
该工具允许将一个 Azure DevOps Server 集合“直接迁移”到一个新的 Azure DevOps Services 组织，但出于以下原因，无需进行任何修改：
为何不允许进行任何修改
- 数据完整性和一致性：迁移期间的修改可能会导致数据损坏或不一致。
- 源数据保留：该工具会忠实地复制源数据，而不会发生任何可能导致差异的更改。
- 可预测行为：限制修改可确保一致、可靠的迁移结果。
- 迁移焦点，而不是转换：工具移动数据;转换在迁移后单独发生。
不支持的迁移方案
- 将项目从一个 Azure DevOps Services 组织移到另一个 Azure DevOps Services 组织
- 从一个 Azure DevOps Server 实例迁移到另一个 Azure DevOps Server 实例
区域限制
数据迁移工具仅在特定的 Azure 区域中受支持。 必须在受支持的区域中创建组织，并且还必须在这些区域中部署任何临时基础结构（例如用于大规模迁移的 SQL VM）。 有关完整列表，请参阅 支持的迁移区域 。
迁移工具过程
- 完成先决条件，例如将 Azure DevOps Server 更新到两个最新版本之一。
- 验证你想要移动到 Azure DevOps Services 的每个集合。
- 生成迁移文件。
- 为迁移过程准备所有内容。
- 执行测试运行。
- 进行迁移。
- 确认用户和数据已迁移，并且集合按预期运行。
小窍门
可以清除迁移之前或之后不需要的数据，以减少迁移时间和存储要求。
选项 3：基于 API 的迁移
如果无法使用数据迁移工具，但仍需要比 选项 2 更高的保真度迁移，请考虑使用使用公共 API 移动数据的各种工具。 这些工具包括在 Visual Studio Marketplace 中提供的扩展。
基于 API 的迁移限制
基于 API 的迁移存在以下限制：
- 低保真迁移：
- 限制：基于 API 的工具提供比手动复制更高的保真度，但保真度仍然相对较低。
- 含义：虽然这些工具提供了一些保真度，但它们并不能保留数据的所有方面。
- 示例：它们都未保留 TFVC 更改集（Team Foundation 版本控制）的原始日期。
- 许多人也不会保留工作项修订的更改日期。
- 数据丢失和 ID 更改：
- 限制：在迁移期间，工具会重播工作项更改、TFVC 更改集、包源和管道工件。
- 含义：此过程可能会导致数据丢失、生成新 ID 以及更改创建、修改和关闭日期。
- 示例：与特定日期关联的历史上下文可能会丢失，从而影响报告和可跟踪性。
基于 API 的迁移过程
一般来说，只有在超出手动复制的额外保真度至关重要的情况下，我们才建议采用这种方法。 如果你决定采用这种方法，你可以考虑聘请一位具有一种或多种工具经验的顾问，并在最终迁移之前进行测试迁移。
许多组织只需对他们工作的一部分进行非常高保真度的迁移。 新工作可能直接在 Azure DevOps Services 中启动。 其他对保真度要求不那么严格的工作，可以使用其他方法进行迁移。
支持的进程模型
Azure DevOps Services 支持以下进程模型：
默认情况下，在 Azure DevOps 服务中，托管 XML 被关闭。 仅当你在 Azure DevOps Server 中自定义项目时，我们才会在迁移过程中启用托管 XML 流程模型。 项目在托管 XML 上后，就可以升级为迁移后继承状态。
关键原则
迁移到 Azure DevOps Services 时，请记住以下关键原则和限制：
- Azure DevOps 服务仅支持英语：Azure DevOps Server 支持多种语言，但目前 Azure DevOps Services 仅支持英语。 如果你的集合使用非英语语言或过去使用非英语，并且你在升级过程中将语言转换为英语，则无法使用数据迁移工具。
- 继承：一个从敏捷、Scrum 或 CMMI 过程模板创建的项目，从来没有定制过，在迁移之后就处于继承过程模型上。
- 托管 XML：具有自定义项的任何项目都使用托管 XML 进程模型。
- 每个自定义项目的过程：尽管 Azure DevOps Services 允许项目共享进程，但数据迁移工具为每个自定义团队项目创建托管 XML 进程。 例如，如果你有 30 个自定义项目，那么你就有 30 个托管 XML 进程要管理。 如果要为所有项目进一步自定义托管 XML 进程，则必须分别更新每个托管 XML 流程。
- 进程验证：数据迁移工具的进程验证检测每个项目的目标进程模型。 在迁移之前，需要修复托管 XML 项目的任何进程验证错误。 你可能需要考虑更新项目的流程，以匹配我们的其中一个流程（敏捷、Scrum 或 CMMI），从而利用继承流程模型。 请参阅我们的文档，了解有关流程验证类型的更多信息。