通过

完成迁移后的任务

  • 项目

迁移完成后，电子邮件将发送到组织所有者，此时，有权访问的任何人都可以登录到新迁移的 Azure DevOps Services 组织。 但是，在使组织可供所有用户使用之前，应完成本文中列出的常见任务。

迁移七个阶段的突出显示迁移后阶段的关系图。

现成检查

组织可用后，立即采取一个小团队，并在组织中发现检查。 建议此团队由项目集合管理员组成。 这种检查不应该深入，而是确保收藏中的主要作品被带过来。

  • 源代码： 验证源代码存储库是否已正确迁移。
  • 生成历史记录： 确保生成历史记录已结束。
  • 区域路径： 确认所有区域路径仍然存在。

这些快速检查有助于在将组织打开到整个用户群之前捕获任何缺失或不完整的数据。

重命名组织（可选）

在 “入门”阶段，你可能已经创建了具有要使用的最终 Azure DevOps Services 组织名称的组织。 如果这是最终迁移，可以将新迁移的 Azure DevOps Services 组织重命名为所需的名称。 有关详细信息，请参阅 重命名组织。

设置帐单

若要为 Azure DevOps 中的用户或服务（如托管生成和部署代理）付费，需要为组织 设置计费 。 如果迁移多个集合，则应确保所有组织都设置为使用同一 Azure 订阅计费，并且为多组织计费启用订阅。 然后，可以在运行迁移的日历月份免费分配任意数量的基本用户。

配置生成代理

如果在 Azure DevOps Server 环境中使用了自动生成或部署服务器，则可以将它们连接到 Azure DevOps Services 组织。 迁移过程中，迁移了所有生成定义，但必须针对新的 Azure DevOps Services 组织重新配置代理和池。

有关详细信息，请参阅 Azure Pipelines 代理。

如果计划使用现有的本地专用生成代理，则必须清除其缓存，这可确保你不会遇到与旧版Team Foundation 版本控制（TFVC）或 Git 指针相关的任何生成问题，这些问题指向本地集合。 有关详细信息，请参阅刷新客户端计算机上的缓存。

提示

如果在 Azure DevOps Server 中使用了发布管理，则迁移了发布管道和历史记录数据。 但与生成一样，必须针对新组织重新配置代理（再次链接）和池。

使用 Azure Artifacts

Azure Artifacts 包含在Azure DevOps Services中，适用于授予基本许可证的所有用户。 无需安装扩展。 迁移后，Azure Artifacts 数据应可用。 有关详细信息，请参阅 Azure Artifacts 概述。

自定义 Azure Boards

如果已有与 Azure DevOps Server 关联的 GitHub Enterprise Server 连接，则它无法按预期工作。 GitHub 中提及的工作项可能会延迟或永远不会显示在 Azure DevOps Services 中。 出现此问题的原因是与 GitHub 关联的回调 URL 不再有效。

若要解决此问题，请考虑以下任务：

  • 删除连接并重新创建连接：删除连接，并重新创建与 GitHub Enterprise Server 存储库的连接。 按照从 Azure Boards 连接文档中提供的步骤顺序操作。
  • 修复 Webhook URL： 转到 GitHub 的存储库设置页并编辑 Webhook URL 以指向已迁移的 Azure DevOps Services 组织 URL： https://dev.azure.com/{OrganizationName}/_apis/work/events?api-version=5.2-preview。

有关详细信息，请参阅 “配置和自定义 Azure Boards”。

检查权限

你的组织包括五个具有 基本 访问权限的免费用户。 有关详细信息，请参阅添加组织用户和管理访问权限。

通知团队

运行生成并配置许可证订阅后，建议向所有用户打开组织进行验证。 然后，单个用户可以确保所有内容都已到位，具有正确的访问级别，并且可以拉取代码。

具有本地工作区的 TFVC 用户必须针对新组织重新映射其工作区，Git 用户必须重新配置其远程服务器以拉取代码。

如果迁移的组织缺少任何内容， 请联系支持人员。

后续步骤

获取 Azure DevOps Services 扩展（可选）