迁移概述
从 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 组织,但出于以下原因,无需进行任何修改:
- 数据完整性和一致性:
- 迁移数据时,保持完整性和一致性至关重要。 在迁移期间允许修改可能会导致数据损坏或不一致。
- 该工具可确保在传输过程中数据保持不变,从而最大程度地降低错误风险。
- 源数据保留:
- 迁移工具旨在忠实地副本 (replica)目标环境中的源数据。
- 修改可能会更改原始数据,这可能会导致迁移的数据与源数据之间存在差异。
- 可预测行为:
- 通过限制修改,该工具可确保迁移过程中的可预测行为。
- 用户可以依赖一致的结果,而不会发生意外更改。
- 迁移焦点,而不是转换:
- 迁移工具的主要用途是将数据从一个位置移到另一个位置。
- 数据转换(如修改值)通常在迁移后单独处理。
可以清除迁移之前或之后不需要的数据。
迁移工具过程
- 完成先决条件,例如将 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),以利用继承过程模型。 在文档中详细了解流程验证类型。
资源
后续步骤
相关文章
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈