验证和导入过程

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

本文将指导完成准备,以便准备好导入到 Azure DevOps Services。 如果在此过程中遇到错误,请参阅 排查导入和迁移错误

先决条件

  • 必须按照 Microsoft Entra 连接 Sync 中所述设置 Microsoft Entra 租户:对默认配置进行更改。 数据迁移工具在导入过程开始时创建 Azure DevOps Services 组织时设置指向 Microsoft Entra 租户的链接。 将本地 Active Directory与 Microsoft Entra ID 同步时,团队成员可以使用相同的凭据进行身份验证,Azure DevOps Services 管理员可以使用 Active Directory 组在 Azure DevOps Services 组织中设置权限。 若要设置同步,请使用 Microsoft Entra 连接 技术。
  • 在开始导入任务之前,检查以确保运行的是受支持的 Azure DevOps Server 版本
  • 建议使用分 步迁移指南 完成导入。 本指南链接到技术文档、工具和最佳做法。

验证集合

验证要迁移到 Azure DevOps Services 的每个集合。 验证步骤检查集合的各个方面,包括但不限于大小、排序规则、标识和流程。

使用数据迁移工具运行验证。

  1. 下载该工具

  2. 将 zip 文件复制到 Azure DevOps Server 应用程序层之一

  3. 解压缩文件。 也可以从未安装 Azure DevOps Server 的其他计算机运行该工具,前提是该计算机可以连接到 Azure DevOps Server 实例的配置数据库。

  4. 在服务器上打开命令提示符窗口,输入 cd 命令以更改为存储数据迁移工具的目录。 花点时间查看该工具的帮助内容。

    a. 若要查看顶级帮助和指南,请运行以下命令:

     Migrator /help
    

    b. 查看命令的帮助文本:

     Migrator validate /help 
    
  5. 首次验证集合时,让我们保持简单。 命令应具有以下结构:

     Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}
    

    例如,如果 {name} 提供 Microsoft Entra 租户的名称,要针对 DefaultCollectionfabrikam 租户运行,该命令将如以下示例所示:

     Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}
    
  6. 若要从Azure DevOps Server以外的计算机运行该工具,需要 /connectionString 参数。 连接字符串参数指向Azure DevOps Server配置数据库。 例如,如果 Fabrikam 公司运行的已验证命令,该命令将如下所示:

     Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"
    

    重要

    数据迁移工具 不会 编辑集合中的任何数据或结构。 它仅读取集合以识别问题。

  7. 验证完成后,可以查看日志文件和结果。

    命令提示符窗口中验证结果和日志的屏幕截图。

    在验证期间,如果某些管道包含每管道保留规则,则会收到警告。 Azure DevOps Services 使用 基于项目的保留模型 ,不支持每管道保留策略。 如果继续迁移,则策略不会传递到托管版本。 相反,将应用默认项目级保留策略。 保留生成对于你来说很重要,以避免其丢失。

完成所有验证后,可以转到 导入过程的下一步。 如果数据迁移工具标记任何错误,请在继续操作之前更正它们。 有关更正验证错误的指南,请参阅 排查导入和迁移错误

导入日志文件

打开日志目录时,你可能会注意到几个日志记录文件。

main日志文件名为 DataMigrationTool.log。 它包含有关已运行的所有内容的详细信息。 为了使你更容易专注于特定区域,日志会为每个主要验证操作生成。

例如,如果 TfsMigrator 在“验证项目进程”步骤中报告错误,则可以打开 ProjectProcessMap.log 文件以查看为该步骤运行的所有内容,而不必滚动浏览整个日志。

仅当尝试导入项目进程以使用继承的模型时,才查看TryMatchOobProcesses.log文件。 如果不想使用继承的模型,可以忽略这些错误,因为它们不会阻止你导入到 Azure DevOps Services。

生成导入文件

数据迁移工具验证了集合,并返回了“所有集合验证通过”的结果。在使集合脱机迁移之前,请生成导入文件。 运行 prepare 命令时,将生成两个导入文件:

  • IdentityMapLog.csv:概述 Active Directory 和 Microsoft Entra ID 之间的标识映射。
  • import.json:要求填写要用于启动迁移的导入规范。

Prepare 命令

命令 prepare 可帮助生成所需的导入文件。 从本质上讲,此命令会扫描集合以查找所有用户的列表,以填充标识映射日志,IdentityMapLog.csv,然后尝试连接到 Microsoft Entra ID 以查找每个标识的匹配项。 为此,公司需要使用 Microsoft Entra 连接 工具(以前称为目录同步工具、目录同步工具或DirSync.exe工具)。

如果设置了目录同步,数据迁移工具应找到匹配的标识并将其标记为“活动”。 如果没有匹配项,则标识在标识映射日志中标记为 “历史记录 ”,因此必须调查用户未包含在目录同步中的原因。导入规范文件 (import.json)应在导入之前填充。

validate与命令不同,prepare需要 Internet 连接,因为它需要连接到 Microsoft Entra ID 来填充标识映射日志文件。 如果 Azure DevOps Server 实例没有 Internet 访问权限,请从执行该操作的计算机运行该工具。 只要可以找到与Azure DevOps Server实例建立 Intranet 连接和 Internet 连接的计算机,就可以运行此命令。 有关 命令的 prepare 帮助,请运行以下命令:

Migrator prepare /help

帮助文档中包括有关从Azure DevOps Server实例本身和远程计算机运行Migrator命令的说明和示例。 如果从Azure DevOps Server实例的应用程序层之一运行命令,则命令应具有以下结构:

Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region}
Migrator prepare  /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True"

connectionString 参数是指向Azure DevOps Server实例的配置数据库的指针。 例如,如果 Fabrikam 公司运行 prepare 命令,该命令将如以下示例所示:

Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

数据迁移工具运行 prepare 命令时,它将运行完整的验证,以确保自上次完全验证以来,集合中没有任何变化。 如果检测到任何新问题,则不会生成任何导入文件。

命令开始运行后不久,会显示 Microsoft Entra 登录窗口。 使用属于该命令中指定的租户域的标识登录。 确保指定的 Microsoft Entra 租户是希望将来的组织得到支持的租户。 在我们的 Fabrikam 示例中,用户输入类似于以下示例屏幕截图的凭据。

重要

不要对测试导入使用测试 Microsoft Entra 租户,不要对生产运行使用生产 Microsoft Entra 租户。 在使用组织的生产 Microsoft Entra 租户开始生产运行时,使用测试 Microsoft Entra 租户可能会导致标识导入问题。

在数据迁移工具中成功运行 prepare 命令后,结果窗口会显示一组日志和两个导入文件。 在日志目录中,找到一个日志文件夹和两个文件:

  • import.json 是导入规范文件。 我们建议你花点时间填写它。
  • IdentityMapLog.csv 包含 Active Directory 到 Microsoft Entra 标识的生成映射。 在开始导入之前,请查看其完整性。

后续部分将更详细地介绍这两个文件。

导入规范文件

导入规范 import.json 是一个提供导入设置的 JSON 文件。 它包括所需的组织名称、存储帐户信息和其他信息。 大多数字段都是自动填充的,某些字段在你尝试导入之前需要你的输入。

新生成的导入规范文件的屏幕截图。

下表描述了 import.json 文件的显示字段和所需操作:

字段 说明 必需的操作
有关用于导入的源数据文件的位置和名称的信息。 无需采取措施。 查看要遵循的子字段操作的信息。
位置 托管数据层应用程序包的 Azure 存储帐户的共享访问签名密钥 (DACPAC) 。 无需采取措施。 此字段将在后面的步骤中介绍。
文件 包含导入数据的文件的名称。 无需采取措施。 查看要遵循的子字段操作的信息。
DACPAC 一个 DACPAC 文件,该文件打包要在导入过程中用于引入数据的集合数据库。 无需采取措施。 在后面的步骤中,使用集合创建此文件,然后将其上传到 Azure 存储帐户。 根据你在此过程稍后生成时使用的名称更新文件。
目标 要导入到的新组织的属性。 无需采取措施。 查看要遵循的子字段操作的信息。
名称 导入期间要创建的组织的名称。 提供一个名称。 导入完成后,可以快速更改名称。
注意在运行导入之前, 请勿创建具有此名称的组织。 组织作为导入过程的一部分创建。
ImportType 要运行的导入类型。 无需采取措施。 在后面的步骤中,选择要运行的导入类型。
验证数据 帮助推动导入体验所需的信息。 数据迁移工具生成“ValidationData”部分。 它包含有助于推动导入体验的信息。 请勿* 编辑本节中的值,否则导入可能无法启动。

完成上述过程后,应有一个如下所示的文件。

部分完成的导入规范文件的屏幕截图。

在上图中,Fabrikam 导入的规划器将组织名称 fabrikam-import 和所选 CUS(中央美国)添加为导入的地理位置。 在规划器使集合脱机进行迁移之前,其他值已保留原样进行修改。

注意

干运行导入自动追加到组织名称末尾的“-dryrun”,可以在导入后更改。

支持导入的 Azure 地理位置

Azure DevOps Services 在多个 Azure 地理位置中可用。 但是,不支持导入 Azure DevOps Services 的所有位置。 下表列出了可以选择导入的 Azure 地理位置。 此外,还包括需要在导入规范文件中放置的值,以针对要导入的地理位置。

地理位置 Azure 地理位置 导入规范值
美国 中央美国 CUS
欧洲 欧洲西部 WEU
英国 英国南部 UKS
澳大利亚 澳大利亚东部 EAU
南美洲 Brazil South Sbr
亚太区 印度南部 MA
亚太区 东南亚(新加坡) SEA
加拿大 加拿大中部 CC

标识映射日志

标识映射日志对迁移到 Azure DevOps Services 的实际数据同样重要。 在查看文件时,请务必了解标识导入的操作方式以及可能产生的结果。 导入标识时,它可以变为 活动 标识或 历史标识。 活动标识可以登录到 Azure DevOps Services,但历史标识无法登录。

活动标识

活动标识是指导入后 Azure DevOps Services 中的用户标识。 在 Azure DevOps Services 中,这些标识已获得许可,并显示为组织中的用户。 标识映射日志文件的“预期导入状态”列中将标识标记为活动

历史标识

在标识映射日志文件的 “预期导入状态” 列中映射历史标识。 文件中没有行条目的标识也将成为历史标识。 没有行条目的标识示例可能是不再在公司工作的员工。

与活动标识不同,历史标识:

  • 迁移后无权访问组织。
  • 没有 许可证。
  • 不要 显示为组织中的用户。 保留的只是该标识在组织中的名称的概念,以便以后可以搜索其历史记录。 建议对不再在公司工作或不需要进一步访问组织的用户使用历史标识。

注意

将标识导入为历史标识后,它 将无法 变为活动状态。

了解标识映射日志文件

标识映射日志文件类似于此处所示的示例:

数据迁移工具生成的标识映射日志文件的屏幕截图。

下表描述了标识映射日志文件中的列:

你和你的 Microsoft Entra 管理员必须调查标记为“找不到匹配”的用户(检查 Microsoft Entra ID 同步),以了解他们为何不是 Microsoft Entra 连接 同步的一部分。

说明
Active Directory:用户 (Azure DevOps Server) 标识在 Azure DevOps Server 中使用的友好显示名称。 通过此名称,可以更轻松地识别地图中线条所引用的用户。
Active Directory:安全标识符 Azure DevOps Server 中本地 Active Directory标识的唯一标识符。 此列用于标识集合中的用户。
Microsoft Entra ID:预期导入用户(Azure DevOps Services) 匹配即将激活的用户的预期登录地址或 “未找到匹配项”(检查 Microsoft Entra ID Sync),指示在 Microsoft Entra ID Sync 期间找不到标识,并导入为历史。
预期导入状态 预期的用户导入状态:Active Directory 和 Microsoft Entra ID 之间存在匹配项;如果没有匹配项,则为“历史记录”。
验证日期 上次验证标识映射日志的时间。

通读文件时,请注意 “预期导入状态” 列中的值是 “活动” 还是 “历史”。 活动 表示此行上的标识在导入时正确映射为活动状态。 历史 意味着标识在导入时成为历史。 请务必查看生成的映射文件的完整性和正确性。

重要

如果 Microsoft Entra 发生重大更改,则导入失败,连接导入尝试之间的安全 ID 同步。 可以在试运行之间添加新用户,并且可以进行更正,以确保以前导入的历史标识变为活动状态。 但是,目前不支持更改以前作为活动状态导入的现有用户。 这样做会导致导入失败。 一个更改示例可能是完成试运行导入,从主动导入的 Microsoft Entra ID 中删除标识,为同一标识在 Microsoft Entra ID 中重新创建一个新用户,然后尝试另一个导入。 在这种情况下,Active Directory 与新创建的 Microsoft Entra 标识之间的活动标识导入尝试,但会导致导入失败。

  1. 查看正确匹配的标识。 是否存在所有预期的标识? 用户是否映射到正确的 Microsoft Entra 标识?

    如果必须更改任何值,请联系 Microsoft Entra 管理员,验证本地 Active Directory标识是否是同步到 Microsoft Entra ID 的一部分,并且已正确设置。 有关详细信息,请参阅 将本地标识与 Microsoft Entra ID 集成。

  2. 接下来,查看标记为 “历史”的标识。 此标记意味着找不到匹配的 Microsoft Entra 标识,原因如下:

    • 未为本地 Active Directory与 Microsoft Entra ID 之间的同步设置标识。
    • 该标识尚未在 Microsoft Entra ID 中填充(例如,有新员工)。
    • Microsoft Entra 实例中不存在标识。
    • 拥有该标识的用户不再在公司工作。

若要解决前三个原因,请设置与 Microsoft Entra ID 同步的预期本地 Active Directory标识。 有关详细信息,请参阅 将本地标识与 Microsoft Entra ID 集成。 必须设置并运行 Microsoft Entra 连接,才能在 Azure DevOps Services 中将标识导入为活动状态。

可以忽略第四个原因,因为不再在公司的员工应作为 历史人员导入。

小型团队 (历史标识)

注意

本部分中建议的标识导入策略只应由小型团队考虑。

如果未配置 Microsoft Entra 连接,则标识映射日志文件中的所有用户都标记为历史。 以这种方式运行导入会导致所有用户都作为 历史用户导入。 强烈建议配置 Microsoft Entra 连接,以确保将用户导入为活动状态。

使用所有历史标识运行导入会产生需要仔细考虑的后果。 只有拥有少数用户的团队,并且设置 Microsoft Entra 连接的成本被视为过高应考虑。

若要将所有标识导入为历史标识,请按照后面的部分中概述的步骤操作。 对导入进行排队时,用于将导入排队的标识作为组织所有者启动到组织中。 所有其他用户作为历史用户导入。 然后 ,组织所有者可以使用其 Microsoft Entra 标识将用户添加回去 。 添加的用户被视为新用户。 他们不拥有其任何历史,并且无法将此历史记录重新分配给 Microsoft Entra 标识。 但是,用户仍可以通过搜索其域><Active Directory 用户名>来查找其<预导入历史记录。

如果数据迁移工具检测到完整的历史标识方案,则会显示一条警告。 如果决定执行此迁移路径,则需要在工具中同意这些限制。

Visual Studio 订阅

数据迁移工具在生成标识映射日志文件时,无法检测 (以前称为 MSDN 权益) 的 Visual Studio 订阅。 相反,我们建议在导入后应用自动许可证升级功能。 只要用户的工作帐户链接正确,Azure DevOps Services导入后首次登录时会自动应用其 Visual Studio 订阅权益。 导入期间分配的许可证永远不会收费,因此以后可以安全地处理订阅。

如果用户的 Visual Studio 订阅未在Azure DevOps Services中自动升级,则无需重复试运行导入。 Visual Studio 订阅链接发生在导入范围之外。 只要在导入之前或之后正确链接了其工作帐户,用户的许可证会在下次登录时自动升级。 成功升级许可证后,下次运行导入时,用户将在首次登录组织时自动升级。

准备导入

现在,已准备好在导入时执行所有操作。 安排团队的停机时间,使集合脱机进行迁移。 同意运行导入的时间时,请将生成的所需资产和数据库的副本上传到 Azure。 准备导入包括以下五个步骤。

步骤 1:使集合脱机并分离。

DACPAC 方法的集合大小限制为 150 GB。 如果数据迁移工具显示无法使用 DACPAC 方法的警告,则必须使用SQL Azure虚拟机 (VM) 方法执行导入。 在这种情况下,请跳过步骤 2 到 5,按照 导入大型集合 中提供的说明操作,然后继续 确定导入类型

步骤 2: 从要导入的集合生成 DACPAC 文件
步骤 3: 上传 DACPAC 文件并将文件导入 Azure 存储帐户
步骤 4: 生成 SAS 令牌以访问存储帐户
步骤 5: 完成导入规范

注意

在执行生产导入之前 ,强烈建议完成 试运行导入。 通过试运行,可以验证导入过程是否适用于集合,并且不存在可能导致生产导入失败的唯一数据形状。

步骤 1:分离集合

分离集合 是导入过程中的关键步骤。 集合的标识数据驻留在 Azure DevOps Server 实例的配置数据库中,而集合已附加并处于联机状态。 当集合与 Azure DevOps Server 实例分离时,它会获取该标识数据的副本,并将其与集合一起打包以便传输。 如果没有此数据,则 无法 执行导入的标识部分。 建议将集合保持分离,直到导入完成,因为导入过程中没有导入发生的更改的方法。

对于试运行(测试)导入,我们建议在备份集合以供导入后重新附加集合,因此你并不担心拥有此类导入的最新数据。 若要完全避免脱机时间,还可以选择对试运行使用 脱机分离

请务必权衡在干运行中选择零停机时间的成本。 它需要备份集合和配置数据库,在 SQL 实例上还原它们,然后创建分离的备份。 成本分析可能证明,只需几个小时的停机时间即可直接执行分离备份, 最终会更好。

步骤 2:生成 DACPAC 文件

DACPAC 提供了一种快速且相对简单的方法,用于将集合移动到Azure DevOps Services。 但是,在集合数据库大小超过特定阈值后,使用 DACPAC 的好处开始减弱。

注意

如果数据迁移工具显示无法使用 DACPAC 方法的警告,则必须使用导入大型集合中提供的SQL Azure虚拟机 (VM) 方法执行导入。

如果数据迁移工具未显示警告,请使用此步骤中所述的 DACPAC 方法。

DACPAC 是 SQL Server 的一项功能,允许将数据库打包到单个文件中,并部署到 SQL Server 的其他实例。 DACPAC 文件也可以直接还原到Azure DevOps Services,因此你可以将其用作在云中获取集合数据的打包方法。

重要

  • 使用SqlPackage.exe时,必须使用 .NET Framework 版本的 SqlPackage.exe 来准备 DACPAC。 MSI 安装程序必须用于安装 .NET Framework 版本的 SqlPackage.exe。 请勿使用 dotnet CLI 或 .zip (Windows .NET 6) 版本的SqlPackage.exe,因为这些版本可能会生成与 Azure DevOps Services 不兼容的 DACPAC。
  • 默认情况下,SqlPackage 版本 161 会加密数据库连接,并且可能无法连接。 如果收到登录进程错误,请添加到 ;Encrypt=False;TrustServerCertificate=True SqlPackage 语句的连接字符串。

使用 SqlPackage 发行说明中的最新 MSI 安装程序下载并安装SqlPackage.exe。

使用 MSI 安装程序后,SqlPackage.exe在类似于 %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\的路径中安装。

生成 DACPAC 时,请记住两个注意事项:保存 DACPAC 的磁盘,以及正在生成 DACPAC 的计算机上的磁盘空间。 你需要确保有足够的磁盘空间来完成该操作。

创建包时,SqlPackage.exe临时将集合中的数据存储在要从中发起打包请求的计算机驱动器 C 上的临时目录中。

你可能会发现驱动器 C 太小,无法支持创建 DACPAC。 可以通过查找集合数据库中的最大表来估计所需的空间量。 DACPAC 一次创建一个表。 运行生成所需的最大空间大致相当于集合数据库中最大表的大小。 如果将生成的 DACPAC 保存到驱动器 C,请考虑从验证运行DataMigrationTool.log文件中报告的集合数据库的大小。

每次运行命令时,DataMigrationTool.log文件都会提供集合中最大表的列表。 有关集合的表大小示例,请参阅以下输出。 将最大表的大小与托管临时目录的驱动器上的可用空间进行比较。

重要

在继续生成 DACPAC 文件之前,请确保 已分离集合。

[Info   @08:23:59.539] Table name                               Size in MB
[Info   @08:23:59.539] dbo.tbl_Content                          38984
[Info   @08:23:59.539] dbo.tbl_LocalVersion                     1935
[Info   @08:23:59.539] dbo.tbl_Version                          238
[Info   @08:23:59.539] dbo.tbl_FileReference                    85
[Info   @08:23:59.539] dbo.Rules                                68
[Info   @08:23:59.539] dbo.tbl_FileMetadata                     61

确保托管临时目录的驱动器具有至少相同数目的可用空间。 如果没有,则需要通过设置环境变量来重定向临时目录。

SET TEMP={location on disk}

另一个注意事项是保存 DACPAC 数据的位置。 将保存位置指向远离远程驱动器可能会导致生成时间更长。 如果快速驱动器(如固态硬盘 (SSD) )在本地可用,建议将驱动器作为 DACPAC 保存位置。 否则,使用收集数据库所在的计算机上的磁盘(而不是远程驱动器)总是会更快。

确定 DACPAC 的目标位置并确保有足够的空间后,就可以生成 DACPAC 文件了。

打开命令提示符窗口并转到SqlPackage.exe位置。 若要生成 DACPAC,请将占位符值替换为所需的值,然后运行以下命令:

SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory
  • 数据源:承载Azure DevOps Server集合数据库的SQL Server实例。
  • 初始目录:集合数据库的名称。
  • targetFile:磁盘上的位置和 DACPAC 文件名。

以下示例显示了在Azure DevOps Server数据层本身上运行的 DACPAC 生成命令:

SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True" /targetFile:C:\DACPAC\Foo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

命令的输出是从集合数据库 Foo.dacpac生成的 DACPAC 文件。

配置集合以便导入

在 Azure VM 上还原集合数据库后,请配置 SQL 登录以允许 Azure DevOps Services 连接到数据库以导入数据。 此登录仅 允许对单一数据库进行读取 访问。

若要开始,请在 VM 上打开SQL Server Management Studio,然后针对要导入的数据库打开新的查询窗口。

将数据库的恢复设置为简单:

ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;

为数据库创建 SQL 登录,并分配该登录“TF标准版XECROLE”:

USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

在 Fabrikam 示例中,这两个 SQL 命令如以下示例所示:

ALTER DATABASE [Foo] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

注意

请确保在 VM 上的SQL Server Management Studio中启用SQL Server和Windows 身份验证模式。 如果未启用身份验证模式,导入将失败。

配置导入规范文件以面向 VM

更新导入规范文件,以包含有关如何连接到 SQL Server 实例的信息。 打开导入规范文件并进行以下更新。

  1. 从源文件对象中删除 DACPAC 参数。

    更改前的导入规范显示在以下代码中。

    更改前的导入规范的屏幕截图。

    更改后的导入规范显示在以下代码中。

    更改后的导入规范的屏幕截图。

  2. 填写所需的参数,并在规范文件中的源对象中添加以下属性对象。

    "Properties":
    {
        "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" 
    }
    

应用更改后,导入规范如以下示例所示。

引用SQL Azure VM 的导入规范的屏幕截图。

导入规范现已配置为使用SQL Azure VM 进行导入。 继续执行其余准备步骤以导入到Azure DevOps Services。 导入完成后,请务必删除 SQL 登录或轮换密码。 导入完成后,Microsoft 不会保留登录信息。

步骤 3:上传 DACPAC 文件

注意

如果使用 SQL Azure VM 方法,只需提供连接字符串。 无需上传任何文件,可以跳过此步骤。

DACPAC 必须放置在 Azure 存储容器中,该容器可以是现有容器,也可以是专门为迁移工作创建的容器。 请务必确保在正确的地理位置创建容器。

Azure DevOps Services 在多个 地理位置可用。 导入到这些位置时,正确放置数据以确保可以成功启动导入至关重要。 数据必须放置在要导入到的同一地理位置。 将数据放置在其他任何位置会导致导入无法启动。 下表列出了用于创建存储帐户和上传数据的可接受地理位置。

所需导入地理位置 存储帐户地理位置
中央美国 中央美国
欧洲西部 欧洲西部
英国 英国南部
澳大利亚东部 澳大利亚东部
巴西南部 Brazil South
印度南部 印度南部
加拿大中部 加拿大中部
亚太(新加坡) 亚太(新加坡)

尽管 Azure DevOps Services 在美国多个地理位置可用,但只有 Central 美国 位置接受新的 Azure DevOps Services。 目前无法将数据导入其他美国 Azure 位置。

可以从Azure 门户创建 Blob 容器。 创建容器后,上传集合 DACPAC 文件。

导入完成后,请使用 AzCopy 或任何其他 Azure 存储资源管理器工具(如Azure 存储资源管理器)来删除 Blob 容器和随附的存储帐户。

注意

如果 DACPAC 文件大于 10 GB,建议使用 AzCopy。 AzCopy 支持多线程上传,可加快上传速度。

步骤 4:生成 SAS 令牌

共享访问签名 (SAS) 令牌提供对存储帐户中资源的委派访问。 通过令牌,你可以为 Microsoft 提供访问数据以执行导入所需的最低特权级别。

可以使用Azure 门户生成 SAS 令牌。 从安全角度来看,我们建议:

  1. 选择“读取 ”和 “列出 ”作为 SAS 令牌的权限。 不需要其他权限。
  2. 设置不超过未来七天的到期时间。
  3. 限制对 Azure DevOps Services IP 的访问。
  4. 将 SAS 令牌置于安全位置。

步骤 5:完成导入规范

在此过程的前面部分填写了导入规范文件,称为 import.json。 此时,你有足够的信息来完成除导入类型以外的所有剩余字段。 稍后将在导入部分介绍导入类型。

import.json规范文件中的“源”下,完成以下字段。

  • 位置:粘贴从脚本生成的 SAS 密钥,然后在上一步中复制。
  • Dacpac:确保文件(包括 .dacpac 文件扩展名)与上传到存储帐户的 DACPAC 文件同名。

最终导入规范文件应如以下示例所示。

已完成的导入规范文件的屏幕截图。

仅限制对Azure DevOps Services IP 的访问

有关详细信息,请参阅 限制对 Azure DevOps Services IP 的访问。

选项 1:使用服务标记

可以通过门户或以编程方式将服务标记添加到azuredevops网络安全组或防火墙,轻松允许来自所有 Azure DevOps Services 地理位置的连接。

选项 2:使用 IpList

IpList使用命令获取需要授予访问权限以允许来自特定 Azure DevOps Services 地理位置的连接的 IP 列表。

帮助文档中包括从 Azure DevOps Server 实例本身和远程计算机运行迁移器的说明和示例。 如果从 Azure DevOps Server 实例的应用程序层之一运行命令,则命令应具有以下结构:

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

可以通过门户或编程方式将 IP 列表添加到网络安全组或防火墙。

确定导入类型

导入可以作为试运行或生产运行排队。 ImportType 参数确定导入类型:

  • DryRun:将试运行用于测试目的。 系统将在 21 天后删除试运行。
  • ProductionRun:如果要保留生成的导入,并在导入完成后在Azure DevOps Services中全职使用组织,请使用生产运行。

提示

我们始终建议先完成试运行导入。

使用导入类型完成的导入规范文件

试运行组织

试运行导入可帮助团队测试其集合的迁移。 预计组织不会永远存在,而是在短时间内存在。 事实上,在可以运行生产迁移之前,必须删除任何已完成的试运行组织。 所有试运行组织 的存在都有限,并在设定的一段时间后自动删除。 有关组织何时被删除的信息包含在成功电子邮件中,应在导入完成后收到。 请务必记下此日期并相应地计划。

大多数试运行组织在删除前 15 天。 如果超过 100 个用户在 导入时拥有基本或更大的许可证,则试运行组织也可以有 21 天的过期时间。 在指定的时间段后,将删除试运行组织。 在执行生产迁移之前,可以根据需要多次重复试运行导入。 在尝试新的试运行之前,需要删除任何以前的试运行。 当团队准备好执行生产迁移时,需要手动删除试运行组织。

有关导入后活动的详细信息,请参阅 导入后 文章。

如果遇到任何导入问题,请参阅 排查导入和迁移错误

运行导入

你的团队现在已准备好开始运行导入过程。 建议先从成功的试运行导入开始,然后再尝试生产运行导入。 通过试运行导入,可以提前查看导入的外观、识别潜在问题,并在进入生产运行之前获得经验。

注意

  • 如果需要对集合重复已完成的生产运行导入(如回滚时),请在将另一个导入排队之前联系 Azure DevOps Services客户支持
  • Azure 管理员可以阻止用户创建新的 Azure DevOps 组织。 如果打开 Microsoft Entra 租户策略,则导入无法完成。 在开始之前,请验证策略未设置,或者执行迁移的用户是否存在异常。 有关详细信息,请参阅 限制通过 Microsoft Entra 租户策略创建组织。
  • Azure DevOps Services 不支持按管道保留策略,它们不会传递到托管版本。

回滚计划的注意事项

对于执行最终生产运行的团队来说,一个共同的关切是他们的回滚计划,如果导入出现问题。 强烈建议执行试运行,以确保可以测试为 Azure DevOps 的数据迁移工具提供的导入设置。

回滚最终生产运行相当简单。 在将导入排入队列之前,请从 Azure DevOps Server 中分离团队项目集合,这使得它对团队成员不可用。 如果出于任何原因需要回滚生产运行并为团队成员恢复本地服务器联机,则可以执行此操作。 再次在本地附加团队项目集合,并通知团队,他们在团队重新组合时继续正常工作,以了解任何潜在的故障。

将导入排队

重要

在继续之前,请确保在生成 DACPAC 文件或将收集数据库上传到SQL Azure VM 之前分离集合。 如果未完成此步骤,导入将失败。 如果导入失败,请参阅 排查导入和迁移错误

使用数据迁移工具的 导入命令启动导入 。 import 命令将导入规范文件作为输入。 它会分析文件以确保提供的值有效,如果成功,它会将导入排队到Azure DevOps Services。 导入命令需要 Internet 连接,但不要求连接到 Azure DevOps Server 实例。

若要开始,请打开命令提示符窗口,并将目录更改为数据迁移工具的路径。 建议查看工具提供的帮助文本。 运行以下命令,查看导入命令的指南和帮助:

Migrator import /help

用于对导入进行排队的命令具有以下结构:

Migrator import /importFile:{location of import specification file}

以下示例演示已完成的导入命令:

Migrator import /importFile:C:\DataMigrationToolFiles\import.json

验证通过后,系统会要求你登录到 Microsoft Entra ID。 请务必使用与生成标识映射日志文件相同的 Microsoft Entra 租户成员的标识登录。 已登录用户是导入组织的所有者。

注意

每个 Microsoft Entra 租户限制为每 24 小时 5 次导入。 只有排队的导入才会计入此上限。

当团队启动导入时,会向排队导入的用户发送电子邮件通知。 在导入排队大约 5 到 10 分钟后,你的团队可以转到组织以检查状态。 导入完成后,团队将被指示登录,并将电子邮件通知发送到组织所有者。