为什么我的工作项迁移花了这么长时间？

Question

我有一个Azure Devops 2019项目，有2200个工作项，我预计这需要不到几个小时。然而，迁移工具花了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

Answer 1

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

Number of revisions

• Number of Attachments

• Number of Links

(链接的链接编号)

2k的工作项转化为20k的节省并不少见，如果您的TFS有汇总插件，甚至200k。我见过每个工作项需要3秒，也有30秒。

此外，当Azure DevOps检测到您正在进行大量调用时，它可能会主动将Rate Limits引入进程，以保护其他用户的服务。这是正常的，没有办法，也不应该有办法。您的迁移永远不应将总统置于生产用户之上。通过转到组织上的/_settings/usage，您可以查看您的使用情况和应用的任何速率限制。

自2016年该工具上线以来，我们添加了一些功能，以帮助加快这一过程：

• 我们现在一次完成工作项、附件和链接；这将减少Azure DevOps服务的负载，并降低速率限制的频率和严重程度。
• 我们还添加了恢复迁移的功能，这也启用了从源系统引入新更改的功能。
• 我们添加了FilterWorkItemsThatAlreadyExistInTarget，以最大限度地减少处理的项目数，但不会阻止带来更改。

提高速度的选项：

1. Only take the Tip -您可以关闭修订版，以便它只执行工作项的一种状态，即最新状态。您可以将ReplayRevisions设置为false以仅写入最新版本，还可以使用CollapseRevisions设置为true来附加一个JSON，使其history.
2. Run更接近目标-所有的长调用都是针对目标的，只有一个对源的查询。我通常会尽量靠近目标运行迁移，所以在与目标相同的数据中心的AzureVM上运行是个不错的选择。但是，如果您的源不是accessible.
3. Scoped Query，您可能会受到限制-如果我正在进行大型迁移，我通常会将第一次运行的查询范围限定为那些当前在我需要尽快启动和运行的团队的范围内的工作项。可能仅限于在过去60天内编辑过的未关闭的工作项。然后我会在后续运行时增加作用域。