我正在Azure DevOps Online(Services)中运行我的项目集合。我想把它迁移到Azure DevOps On-Prem Server。
帮助我解决我将面临的不兼容问题以及如何克服这个问题。
从Azure DevOps online(services)迁移到Azure DevOps Server(On-Prem)的选项。
azure中是否有任何可用的服务可以在不丢失任何数据的情况下成功实现上述迁移?
我是否必须使用第三方工具进行上述迁移而不丢失任何数据?
帮助我在这里与100 GB的项目收集与多个存储库所需的停机时间。
项目集合大小- 100gb
前面的一个答案(已经删除?)已经捕获了大多数关键点，并且没有工具可以在零数据丢失的情况下迁移100%的数据(实际上，100%的迁移没有丢失是不可实现的，因为一些自动生成的和配置值，如工作项id等，在两个实例之间本质上是不同的)。因此，获得零数据丢失迁移的唯一方法是将完整的项目集合映像从Azure DevOps Services提升并转移到Azure DevOps Server，这是官方Azure DevOps迁移工具不支持的。鉴于此，迁移数据的唯一方法就是使用Azure DevOps api。
因此，最好的方法是了解您正在评估的迁移工具不能迁移哪些数据，然后决定最适合您的方法。此外，在选择迁移解决方案时，也不会是非黑即白的选择。首先，您需要定义您期望从迁移中获得的必备功能，然后评估市场上可用的不同迁移器。以下是一些常见的选择标准:
- 数据丢失:
了解迁移解决方案可以迁移哪些数据，不能迁移哪些数据。理想情况下，该工具应该能够迁移工作项(连同历史记录、附件、提及和内联图像)和测试管理，包括测试结果、源代码、仪表板、区域和迭代。对于构建和管道，您可以使用本地的Export-Import特性，因为它们需要手动更改以调整连接。
- 零停机时间:
停机时间增加了运营成本并影响开发操作，因为团队无法使用Azure DevOps工具。彻底理解不存在任何类型的数据需要停机的场景。
- 易用性:
一些工具是不受支持的脚本(Naked Agility)的集合，需要非常高的复杂度才能使用。这些脚本可能非常昂贵(即使脚本是开源的)，容易出错并且妨碍操作。
- 项目整合或自定义模板:
分析您是否希望在迁移时将多个项目合并到一个项目中，或者是否需要自定义模板。如果需要这样做，请评估迁移工具是否能够轻松地支持这种配置，并具有这样做的UI。手动配置每个项目的映射可能很繁琐，而且很容易出错。
- 迁移时间:
许多迁移工具逐个迁移项目，因此要花费大量的精力和时间来迁移分布在多个项目中的数据。了解有多少项目可以并行迁移以获得快速迁移。
- 反向同步:
您是否希望在迁移后的一段时间内保持服务和服务器之间的数据同步?数据是双向集成还是单向集成?回答这些问题，然后评估迁移解决方案是否满足需求。
- 商业支持:
迁移可能是棘手且耗时的，因为随着时间的推移，不同的团队已经在其中创建了所有奇怪的东西。当您专注于定义需求和验证迁移的完整性时，最好有一个专家团队为您完成迁移。
完全披露:我为OpsHub工作。