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