验证和导入过程

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

本文将引导你完成准备，使导入Azure DevOps Services准备好运行。 如果在过程中遇到错误，请参阅 排查导入和迁移错误。

注意

• Visual Studio Team Services (VSTS) 现已Azure DevOps Services。
• 随着 Azure DevOps Server 2019 的发布，TFS 数据库导入服务已重新命名为 Azure DevOps 的数据迁移工具。 此更改包括 TfsMigrator (Migrationor) 成为数据迁移工具。 此服务的工作方式与以前的导入服务完全相同。 如果使用 TFS 品牌运行较旧版本的本地Azure DevOps Server，只要已升级到受支持的服务器版本之一，仍可使用此功能迁移到 Azure DevOps。
• 在开始导入任务之前，请检查以确保运行受支持的Azure DevOps Server版本。

建议使用 分步迁移指南 完成导入。 本指南链接到技术文档、工具和最佳做法。

先决条件

• 必须按描述的 Azure AD Connect 同步设置 Azure Active Directory 租户：对默认配置进行更改。 数据迁移工具在导入过程开始时创建Azure DevOps Services组织时设置指向 Azure Active Directory 租户的链接。

  通过将本地 Active Directory与 Azure Active Directory 同步，团队成员将能够使用相同的凭据进行身份验证，Azure DevOps Services管理员将能够利用 Active Directory 组在Azure DevOps Services中设置权限组织。 若要设置同步，需要使用 Azure AD Connect 技术。

验证集合

确认正在运行最新版本的Azure DevOps Server后，下一步是验证要迁移到Azure DevOps Services的每个集合。

验证步骤检查集合的各个方面，包括但不限于大小、排序规则、标识和进程。

使用数据迁移工具运行验证。 若要开始，请下载该工具，将 zip 文件复制到Azure DevOps Server应用程序层之一，然后将其解压缩。 也可以从未安装Azure DevOps Server的其他计算机运行该工具，前提是计算机可以连接到Azure DevOps Server实例的配置数据库。 此处显示了一个示例。

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

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

    Migrator /help
   

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

    Migrator validate /help 
   

2. 因为这是你第一次验证集合，因此让我们保持简单。 命令应具有以下结构：

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

   其中 {name} 提供 Azure Active Directory 租户的名称。 例如，若要针对 DefaultCollection 和 fabrikam 租户运行，该命令如下所示：

    Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com
   

3. 若要从 Azure DevOps Server 以外的计算机运行该工具，需要 /connectionString 参数。 连接字符串参数指向Azure DevOps Server配置数据库。 例如，如果验证命令由 Fabrikam 公司运行，该命令将如下所示：

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

   重要

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

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

   

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

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

导入日志文件

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

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

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

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

生成导入文件

现在，你已针对集合运行数据迁移工具验证，并返回“所有已传递的集合验证”的结果。在使集合脱机迁移之前，需要生成导入文件。 运行此命令 prepare 时，将生成两个导入文件：

• IdentityMapLog.csv：概述 Active Directory 与 Azure Active Directory (Azure AD) 之间的标识映射。
• import.json：需要填写要用于开始迁移的导入规范。

prepare 命令

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

如果设置了目录同步，数据迁移工具应能够找到匹配的标识并将其标记为 “活动”。 如果找不到匹配项，则标识在标识映射日志中标记为 “历史 ”，你需要调查用户为何未包含在目录同步中。导入规范文件 import.json 应在导入之前填写。

validate与命令不同，prepare需要 Internet 连接，因为它需要连接到 Azure AD 以填充标识映射日志文件。 如果Azure DevOps Server实例没有 Internet 访问权限，则需要从执行该操作的计算机运行该工具。 只要可以找到一台具有与 Azure DevOps Server 实例和 Internet 连接的 Intranet 连接的计算机，就可以运行以下命令。 有关该命令的 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实例的配置数据库的指针。 例如，如果 prepare 命令由 Fabrikam 公司运行，该命令将如下所示：

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

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

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

重要

不要对测试导入使用测试 Azure AD 租户，不要将生产 Azure AD 租户用于生产运行。 在使用组织的生产 Azure AD 租户开始生产运行时，使用测试 Azure AD 租户可能会导致标识导入问题。

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

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

下一节将更详细地介绍这两个文件。

导入规范文件

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

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

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

完成上述过程后，应有如下所示的文件：

在上图中，请注意 Fabrikam 导入的规划器添加了组织名称 fabrikam-import，并选择了 CUS (Central 美国) 作为要导入的区域。 在规划器脱机迁移集合之前，其他值将保留为修改。

注意

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

支持的用于导入的 Azure 区域

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

地理区域	Azure 区域	导入规范值
美国	中央美国	CUS
欧洲	欧洲西部	WEU
United Kingdom	英国南部	UKS
澳大利亚	澳大利亚东部	EAU
南美洲	巴西南部	Sbr
亚太区	印度南部	MA
亚太区	东南亚（新加坡）	SEA
Canada	加拿大中部	CC

标识映射日志

标识映射日志对要迁移到Azure DevOps Services的实际数据同样重要。 查看文件时，请务必了解标识导入的工作原理以及潜在结果可能带来什么。 导入标识时，它可以变为 活动 或 历史。 活动标识可以登录到Azure DevOps Services，但历史标识无法登录。

活动标识

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

历史标识

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

与活动标识不同，历史标识：

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

注意

将标识导入为历史标识后， 它将无法 处于活动状态。

了解标识映射日志文件

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

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

注意

你和 Azure AD 管理员需要调查标记为“找不到匹配”的用户 (检查Azure AD Sync) 了解他们为何不属于 Azure AD Connect 同步。

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

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

重要

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

1. 首先查看正确匹配的标识。 是否存在所有预期的标识？ 用户是否映射到正确的 Azure AD 标识？

   如果任何值映射不正确或需要更改，请联系 Azure AD 管理员，验证本地 Active Directory标识是否是同步到 Azure AD 的一部分，并且已正确设置。 有关详细信息，请参阅 将本地标识与 Azure Active Directory 集成。

2. 接下来，查看标记为 历史标识的标识。 此标记意味着找不到匹配的 Azure AD 标识，原因如下：

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

若要解决前三个原因，需要设置预期本地 Active Directory标识以与 Azure AD 同步。 有关详细信息，请参阅 将本地标识与 Azure Active Directory 集成。 必须设置并运行 Azure AD Connect，以便标识在Azure DevOps Services中作为活动状态导入。

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

(小团队) 的历史标识

注意

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

如果尚未配置 Azure AD Connect，你会注意到标识映射日志文件中的所有用户都标记为 历史。 以这种方式运行导入会导致所有用户作为 历史导入。 强烈建议配置 Azure AD Connect 以确保将用户导入为 活动状态。

运行具有所有历史标识的导入会产生需要仔细考虑的后果。 应仅由拥有少量用户且设置 Azure AD Connect 的成本过高的团队考虑。

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

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

Visual Studio 订阅

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

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

准备导入

现在，你已准备好在导入时执行所有操作。 你需要安排团队的停机时间，使集合脱机进行迁移。 在一次运行导入时，需要将所需资产和数据库副本上传到 Azure。 此过程有五个步骤：

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

注意

如果数据迁移工具显示一条警告，指出无法使用 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 的其他实例。 DACPAC 文件也可以直接还原到Azure DevOps Services，因此可以将它用作打包方法，用于在云中获取集合的数据。 使用SqlPackage.exe工具生成 DACPAC 文件。 该工具包含在 SQL Server Data Tools (SSDT) 中。

SqlPackage.exe工具的多个版本随 SSDT 一起安装。 版本存储在名称为 120、130 和 140 的文件夹中。 使用SqlPackage.exe时，请务必使用正确的版本来准备 DACPAC。

• TFS 2018 导入需要使用 140 文件夹或更高版本中的SqlPackage.exe版本。

如果安装了 SSDT for Visual Studio，则会在以下文件夹路径之一中找到SqlPackage.exe版本：

• 如果安装了 SSDT 并将其与 Visual Studio 的现有安装集成，则SqlPackage.exe文件夹路径类似于 C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\。
• 如果将 SSDT 安装为独立安装，则SqlPackage.exe文件夹路径类似于 C:\Program Files (x86)\Microsoft Visual. Studio\2017\SQL\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130\。
• 如果已安装SQL Server，则SqlPackage.exe可能已存在，并且文件夹路径类似于%PROGRAMFILES%\Microsoft SQL Server\130\DAC\bin\。

可从SQL Server Data Tools下载的两个 SSDT 版本包括 130 和 140 个文件夹及其SqlPackage.exe版本。

生成 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 登录名，并为该登录名分配“TFSEXECROLE”：

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" 
   }
   

按照 Fabrikam 示例应用更改后，导入规范如下所示：

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

步骤 3：上传 DACPAC 文件

注意

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

DACPAC 必须放置在 Azure 存储容器中。 这可以是为迁移工作专门创建的现有容器或容器。 请务必确保容器在正确的区域中创建。

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

所需导入区域	存储帐户区域
中央美国	中央美国
欧洲西部	欧洲西部
United Kingdom	英国南部
澳大利亚东部	澳大利亚东部
巴西南部	巴西南部
印度南部	印度南部
加拿大中部	加拿大中部
亚太（新加坡）	亚太（新加坡）

尽管Azure DevOps Services在美国的多个区域中可用，但只有中央美国区域接受新的Azure DevOps Services。 目前无法将数据导入其他美国 Azure 区域。

可以从Azure 门户创建 Blob 容器。 创建容器后，需要上传 Collection DACPAC 文件。

导入完成后，可以删除 Blob 容器和随附的存储帐户。 为此，可以使用 AzCopy 或任何其他 Azure 存储资源管理器工具，例如Azure 存储资源管理器。

注意

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

步骤 4：生成 SAS 密钥

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

生成 SAS 密钥的建议方法是使用Azure 存储资源管理器。 借助存储资源管理器，可以轻松创建容器级 SAS 密钥。 这一点至关重要，因为数据迁移工具 不支持 帐户级 SAS 密钥。

注意

请勿从 Azure 门户生成 SAS 密钥。 Azure 门户生成的 SAS 密钥是帐户范围的，不适用于数据迁移工具。

安装存储资源管理器后，可以通过执行以下操作生成 SAS 密钥：

1. 打开存储资源管理器。

2. 添加帐户。

3. 选择 “使用存储帐户名称和密钥”，然后选择“ 连接”。

   

4. 在 “附加外部存储 ”窗格中，输入存储帐户名称，提供两 个主要访问密钥之一，然后选择“ 连接”。

   

5. 在左窗格中，展开 Blob 容器，右键单击存储导入文件的容器，然后选择“ 获取共享访问签名”。

   

6. 对于 到期时间，设置将来七天的到期日期。

   

7. 在 SAS 密钥 的权限 下，选中“ 读取 ”和“ 列表 ”复选框。 不需要写入和删除权限。

   注意

   • 复制此 SAS 密钥并将其存储在下一步的导入规范文件中。
   • 将此 SAS 密钥视为机密。 它提供对存储容器中文件的访问权限。

步骤 5：完成导入规范

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

在 import.json 规范文件中的 “源”下，完成以下字段：

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

使用 Fabrikam 示例时，最终导入规范文件应如下所示：

仅限制对 Azure DevOps Services IP 的访问

强烈建议将对 Azure 存储帐户的访问限制为仅从 Azure DevOps Services 访问 IP。 为此，仅允许来自集合数据库导入过程中涉及的Azure DevOps Services IP 集的连接。 需要授予存储帐户访问权限的 IP 取决于要导入到的区域。 使用 IpList 选项获取需要授予访问权限的 IP 列表。

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

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

注意

或者，还可以使用 服务标记 代替显式 IP 范围。 Azure 服务标记是客户管理其网络配置以允许来自特定 Azure 服务的流量的便捷方法。 客户可以通过门户或以编程方式将标记名称 azuredevops 添加到其网络安全组或防火墙，轻松允许访问。

确定导入类型

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

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

提示

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

干运行组织

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

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

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

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

运行导入

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

注意

如果需要对集合重复已完成的生产运行导入，如回滚时一样，请在对另一个导入进行排队之前联系Azure DevOps Services客户支持。

注意

Azure 管理员可以阻止用户创建新的 Azure DevOps 组织。 如果已启用 Azure AD 租户策略，则导入将失败。 在开始之前，请验证策略是否未设置，或者执行迁移的用户存在异常。 有关详细信息，请参阅 限制通过 Azure AD 租户策略创建组织。

注意

Azure DevOps Services不支持每个管道的保留策略，它们不会传递到托管版本。

回滚计划的注意事项

对于正在执行最终生产运行的团队来说，一个共同的关切是，如果导入有任何问题，他们的回滚计划会是什么。 这就是为什么我们强烈建议执行干运行，以确保能够测试为 Azure DevOps 的数据迁移工具提供的导入设置。

最终生产运行的回滚非常简单。 在对导入进行排队之前，请从 Azure DevOps Server 或 Team Foundation 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

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

注意

每个 Azure AD 租户限制为每 24 小时 5 次导入。 仅针对此上限排队计数的导入。

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

相关文章

• 迁移选项
• 导入后