1

我有一个包含 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
4

1 回答 1

1

每个工作项的迁移长度取决于：

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

如果您的 TFS 有汇总插件，2k 工作项变成 20k 保存甚至 200k 的情况并不少见。我已经看到每个工作项需要 3 秒，还有 30 秒。

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

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

  • 我们现在一次性完成工作项、附件和链接；这减少了 Azure DevOps 服务的负载，并降低了速率限制的频率和严重性。
  • 我们还添加了恢复迁移的功能，这也使我们能够从源系统中引入新的更改。
  • 我们已经添加FilterWorkItemsThatAlreadyExistInTarget以最小化处理的项目数量，但这并不是说这会阻止更改发生。

加速选项：

  1. 只接受提示- 您可以关闭修订，以便它只执行工作项的 1 个状态，即最新的。你可以设置ReplayRevisions为false只写最新的，你可以使用CollapseRevisions设置true来附加一个带有历史记录的 JSON。
  2. 靠近目标运行- 所有长调用都针对目标，仅针对源进行一次查询。我通常尝试在尽可能靠近目标的地方运行迁移，因此在与目标相同的数据中心中运行 AzureVM 是一个不错的选择。但是，如果您的来源不可访问，您可能会受到限制。
  3. Scoped Query - 如果我正在进行大规模迁移，我通常会将第一次运行的查询范围仅限于那些目前在我需要尽快启动和运行的团队范围内的工作项。可能只有在过去 60 天内编辑过的非关闭工作项。然后我会增加后续运行的范围。
于 2020-10-16T08:39:35.107 回答