为什么我的工作项迁移需要这么长时间？

问题描述

我有一个包含2200个工作项的Azure Devops 2019项目，我希望这将花费不到几个小时的时间。但是，迁移工具花了3天以上的时间才能完成。这是正常的迁移时间，还是我们的设置或工具可能有问题？

我发现日志记录中似乎没有任何作用的空白

10:33:35 WotrkItemQuery: keyToFiund: XXX
10:33:55 [Test Case] [Complete: 1606/2215] work item has 2 revisions and revision migration is set to True
10:44:16: [Test Case] [Complete 1606/2215] Found 2 revisions to migrate on Work Item:XXX

解决方法

每个工作项的迁移时间取决于：

1. 修订数量
2. 附件数
3. 链接数

将2k个工作项转换为20k节省的情况并不少见，如果您的TFS有汇总插件，甚至节省200k。我已经看到每个工作项目需要3秒钟，也需要30秒钟。

此外，当Azure DevOps检测到您正在打很多电话时，它可能会在过程中积极引入Rate Limits，以保护其他用户的服务。这是正常现象，没有办法解决，也没有办法。您的迁移绝不能取代生产用户。通过转到组织上的/_settings/usage，您可以查看自己的使用情况和所应用的任何速率限制。

自该工具于2016年推出以来，我们已添加了一些功能以帮助加快流程：

• 我们现在一次完成工作项，附件和链接；这样可以减少Azure DevOps服务的负载，并降低速率限制的频率和严重程度。
• 我们还增加了恢复迁移的功能，这还使我们能够从源系统中获取新更改。
• 我们添加了FilterWorkItemsThatAlreadyExistInTarget，以最大程度地减少已处理项目的数量，但这并不是防止更改被带来。

加速选项：

1. 仅接受提示-您可以轮流进行修订，以便它仅对工作项执行1种状态，即最新状态。您可以将ReplayRevisions设置为false以仅写入最新消息，也可以使用CollapseRevisions设置为true来将JSON附加到历史记录中。
2. 更接近目标-所有长通话都针对目标，仅针对源一个查询。我通常尝试将迁移程序尽可能地靠近目标，因此在与目标相同的数据中心中的AzureVM上运行是一个很好的选择。但是，如果您的来源无法访问，您可能会受到限制。
3. 范围内的查询-如果我进行的是大型迁移，我通常会在第一次运行时将查询范围限定为仅适用于那些我现在需要上岗的团队的当前工作项目。运行最快。也许只有过去60天内编辑过的非关闭工作项目。然后，我将扩大后续运行的范围。