您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

将 Team Foundation Server 部署重构到 Azure DevOps ServicesRefactor a Team Foundation Server deployment to Azure DevOps Services

本文说明了虚构公司 Contoso 如何通过将其迁移到 Azure 中的 Azure DevOps Services 来重构其本地 Visual Studio Team Foundation Server 部署。This article shows how the fictional company Contoso refactors its on-premises Visual Studio Team Foundation Server deployment by migrating it to Azure DevOps Services in Azure. Contoso 开发团队已使用 Team Foundation Server 在过去五年中进行团队协作和源代码管理。The Contoso development team has used Team Foundation Server for team collaboration and source control for the past five years. 现在,团队想要迁移到基于云的解决方案以进行开发和测试工作以及进行源代码管理。Now, the team wants to move to a cloud-based solution for dev and test work and for source control. 在 Contoso 团队迁移到 Azure DevOps 模型和开发新的云本机应用程序时,将扮演一个角色。 Azure DevOps ServicesAzure DevOps Services will play a role as the Contoso team moves to an Azure DevOps model and develops new cloud-native applications.

业务驱动因素Business drivers

Contoso IT 领导团队与业务合作伙伴密切合作,以确定未来的目标。The Contoso IT leadership team has worked closely with business partners to identify future goals. 合作伙伴并不关心开发工具和技术,但团队已捕获以下要点:The partners aren't overly concerned with dev tools and technologies, but the team has captured these points:

  • 软件: 不管是什么核心业务,所有公司现在都是软件公司,包括 Contoso。Software: Regardless of the core business, all companies are now software companies, including Contoso. 业务领导对其如何帮助公司提供用户的新工作实践以及为其客户提供的新体验感兴趣。Business leadership is interested in how IT can help lead the company with new working practices for users and new experiences for its customers.
  • 效率: Contoso 需要简化其流程,并为开发人员和用户删除不必要的过程。Efficiency: Contoso needs to streamline its processes and remove unnecessary procedures for developers and users. 这样,公司就可以更有效地交付客户需求。Doing so will allow the company to deliver on customer requirements more efficiently. 业务需要它快速移动,而不会浪费时间或金钱。The business needs IT to move quickly, without wasting time or money.
  • 灵活性: 为了在全球经济中实现成功,Contoso 需要更好地响应业务需求。Agility: To enable its success in a global economy, Contoso IT needs to be more responsive to the needs of the business. 它必须能够更快地响应 marketplace 中的更改。It must be able to react more quickly to changes in the marketplace. 它不能以这种方式获取或成为企业阻止。IT must not get in the way or become a business blocker.

迁移目标Migration goals

Contoso 云团队已将以下目标迁移到 Azure DevOps Services:The Contoso cloud team has pinned down the following goals for its migration to Azure DevOps Services:

  • 团队需要使用工具将其数据迁移到云。The team needs a tool to migrate its data to the cloud. 一些流程需要手动执行。Few manual processes should be needed.
  • 上一年的工作项数据和历史记录必须迁移。Work item data and history for the last year must be migrated.
  • 团队不想设置新的用户名和密码。The team doesn't want to set up new user names and passwords. 必须保留当前的所有系统分配。All current system assignments must be maintained.
  • 团队希望从 Team Foundation Version Control (TFVC) 迁移到 Git 来进行源代码管理。The team wants to move away from Team Foundation Version Control (TFVC) to Git for source control.
  • 过渡到 Git 将是只导入最新版本的源代码的 tip 迁移。The transition to Git will be a tip migration that imports only the latest version of the source code. 在发生故障时,将在一段时间内停止所有工作,因为基本代码会发生变化。The transition will happen during a downtime, when all work will be halted as the code base shifts. 团队了解,在移动后只有当前主分支历史记录才可用。The team understands that only the current main branch history will be available after the move.
  • 团队关心更改,并想要在执行完整移动之前对其进行测试。The team is concerned about the change and wants to test it before it does a full move. 即使在迁移到 Azure DevOps Services 之后,团队仍希望保留对 Team Foundation Server 的访问权限。The team wants to retain access to Team Foundation Server even after the move to Azure DevOps Services.
  • 团队有多个集合,为了更好地了解该过程,它想要从只包含几个项目的过程开始。The team has multiple collections and, to better understand the process, it wants to start with one that has only a few projects.
  • 团队了解 Team Foundation Server 集合与 Azure DevOps Services 组织之间存在一对一的关系,因此它将具有多个 Url。The team understands that Team Foundation Server collections are a one-to-one relationship with Azure DevOps Services organizations, so it will have multiple URLs. 但它与代码库和项目的当前分离模型相匹配。But this matches its current model of separation for code bases and projects.

建议的体系结构Proposed architecture

  • Contoso 会将其 Team Foundation Server 项目移动到云中,并且它将不再在本地托管其项目或源代码管理。Contoso will move its Team Foundation Server projects to the cloud, and it will no longer host its projects or source control on-premises.
  • Team Foundation Server 将迁移到 Azure DevOps Services。Team Foundation Server will be migrated to Azure DevOps Services.
  • 目前,Contoso 有一个名为的 Team Foundation Server 集合 ContosoDev ,该集合将迁移到名为的 Azure DevOps Services 组织 contosodevmigration.visualstudio.comCurrently, Contoso has one Team Foundation Server collection, named ContosoDev, which will be migrated to an Azure DevOps Services organization called contosodevmigration.visualstudio.com.
  • 最后一年的项目、工作项、bug 和迭代将迁移到 Azure DevOps Services。The projects, work items, bugs, and iterations from the last year will be migrated to Azure DevOps Services.
  • Contoso 将使用它的 Azure Active Directory (Azure AD) 实例,该实例在迁移规划开始 部署 Azure 基础结构 时进行设置。Contoso will use its Azure Active Directory (Azure AD) instance, which it set up when it deployed its Azure infrastructure at the beginning of the migration planning.


迁移过程Migration process

Contoso 将按如下方式完成迁移进程:Contoso will complete the migration process as follows:

  1. 需要进行重要的准备工作。Significant preparation is required. 首先,Contoso 必须将其 Team Foundation Server 实现升级到受支持的级别。First, Contoso must upgrade its Team Foundation Server implementation to a supported level. Contoso 当前正在 Team Foundation Server 2017 更新3运行,但若要使用数据库迁移,则需要使用最新更新运行受支持的2018版本。Contoso is currently running Team Foundation Server 2017 Update 3, but to use database migration it needs to run a supported 2018 version with the latest updates.
  2. Contoso 升级后,它将运行 Team Foundation Server 迁移工具并验证其集合。After Contoso upgrades, it will run the Team Foundation Server migration tool and validate its collection.
  3. Contoso 将生成一组准备文件,然后执行迁移模拟运行以进行测试。Contoso will build a set of preparation files and then perform a migration dry run for testing.
  4. 然后,Contoso 将运行另一个迁移,这次是包括工作项、bug、冲刺 (sprint) 和代码在内的完整迁移。Contoso will then run another migration, this time a full migration that includes work items, bugs, sprints, and code.
  5. 迁移后,Contoso 会将其代码从 TFVC 移至 Git。After the migration, Contoso will move its code from TFVC to Git.

Contoso 迁移过程的示意图。


若要运行此方案,Contoso 需要满足以下先决条件:To run this scenario, Contoso needs to meet the following prerequisites:

要求Requirements 详细信息Details
Azure 订阅Azure subscription 在前面的系列文章中,Contoso 已创建订阅。Contoso created subscriptions in an earlier article in this series. 如果还没有 Azure 订阅,可以创建一个免费帐户If you don't have an Azure subscription, create a free account.

如果创建的是免费帐户,则你是自己的订阅的管理员,可以执行所有操作。If you create a free account, you're the administrator of your subscription and can perform all actions.

如果你使用现有订阅并且不是管理员,则需要请求管理员为你分配“所有者”或“参与者”权限。If you use an existing subscription and you're not the administrator, you need to work with the admin to assign you Owner or Contributor permissions.

如果需要更精细的权限,请参阅 使用 AZURE RBAC) (管理 Site Recovery 访问 If you need more granular permissions, see Manage Site Recovery access with Azure role-based access control (Azure RBAC).
Azure 基础结构Azure infrastructure Contoso 根据 用于迁移的 azure 基础结构中所述设置其 azure 基础结构。Contoso set up its Azure infrastructure as described in Azure infrastructure for migration.
本地 Team Foundation Server 实例On-premises Team Foundation Server instance 在此过程中,本地实例需要运行 Team Foundation Server 2018 升级2或升级到该实例。The on-premises instance needs to either run Team Foundation Server 2018 upgrade 2 or be upgraded to it as part of this process.

方案步骤Scenario steps

下面是 Contoso 完成迁移的步骤:Here's how Contoso will complete the migration:

  • 步骤1:创建 Azure 存储帐户Step 1: Create an Azure storage account. 在迁移过程中将使用此存储帐户。This storage account will be used during the migration process.
  • 步骤2:升级 Team Foundation ServerStep 2: Upgrade Team Foundation Server. Contoso 会将其部署升级到 Team Foundation Server 2018 升级2。Contoso will upgrade its deployment to Team Foundation Server 2018 upgrade 2.
  • 步骤3:验证 Team Foundation Server 集合Step 3: Validate the Team Foundation Server collection. Contoso 将验证 Team Foundation Server 集合,以便为迁移做准备。Contoso will validate the Team Foundation Server collection in preparation for the migration.
  • 步骤4:生成迁移文件Step 4: Build the migration files. Contoso 将使用 Team Foundation Server 迁移工具创建迁移文件。Contoso will create the migration files by using the Team Foundation Server migration tool.

步骤1:创建 Azure 存储帐户Step 1: Create an Azure Storage account

  1. 在 Azure 门户中,Contoso 管理员 () 创建存储帐户 contosodevmigrationIn the Azure portal, Contoso admins create a storage account (contosodevmigration).

  2. 它们将帐户放在辅助区域中,用于故障转移 (Central US) 。They place the account in the secondary region, which they use for failover (Central US). 管理员使用具有本地冗余存储的常规用途标准帐户。They use a general-purpose standard account with locally redundant storage.

    "创建存储帐户" 窗格的屏幕截图。

需要更多帮助?Need more help?

步骤2:升级 Team Foundation ServerStep 2: Upgrade Team Foundation Server

Contoso 管理员将 Team Foundation Server 实例升级到 Team Foundation Server 2018 Update 2。Contoso admins upgrade the Team Foundation Server instance to Team Foundation Server 2018 Update 2. 在开始之前,它们:Before they start, they:

他们如下所述进行升级:They upgrade as follows:

  1. 若要开始,管理员需要备份其 Team Foundation Server 实例,该实例在 VMware 虚拟机上运行 (VM) ,并使用 VMware 快照。To start, the admins back up their Team Foundation Server instance, which is running on a VMware virtual machine (VM), and they take a VMware snapshot.

    用于升级 Team Foundation Server 的 * * 入门 "窗格的屏幕截图。

  2. 将启动 Team Foundation Server 安装程序,并选择安装位置。The Team Foundation Server installer starts, and they choose the installation location. 安装程序需要访问 Internet。The installer needs internet access.

    Visual Studio 中的 Team Foundation Server 安装站点的屏幕截图。

  3. 在安装完成后,服务器配置向导启动。After the installation finishes, the Server Configuration Wizard starts.

    Team Foundation Server 2018 Update 2 配置向导的屏幕截图。

  4. 验证完成后,服务器配置向导完成升级。After verification, the Server Configuration Wizard completes the upgrade.

    Team Foundation Server 配置向导的 "升级进度" 窗格的屏幕截图。

  5. 管理员通过查看项目、工作项和代码来验证 Team Foundation Server 安装。The admins verify the Team Foundation Server installation by reviewing projects, work items, and code.

    用于验证 Team Foundation Server 安装的 "产品积压工作(backlog)" 窗格的屏幕截图。


某些 Team Foundation Server 升级需要在升级完成后运行配置功能向导。Some Team Foundation Server upgrades need to run the Configure Features Wizard after the upgrade finishes. 了解详细信息Learn more.

需要更多帮助?Need more help?

了解 升级 Team Foundation ServerLearn about upgrading Team Foundation Server.

步骤3:验证 Team Foundation Server 集合Step 3: Validate the Team Foundation Server collection

Contoso 管理员对集合数据库运行 Team Foundation Server 迁移工具 contosodev ,以在迁移前对其进行验证。Contoso admins run the Team Foundation Server migration tool against the contosodev collection database to validate it before migration.

  1. 它们下载并解压缩 Team Foundation Server 迁移工具They download and unzip the Team Foundation Server migration tool. 下载正在运行的 Team Foundation Server 更新的版本很重要。It's important to download the version for the Team Foundation Server update that's running. 可以在管理控制台中检查版本。The version can be checked in the admin console.

    用于验证产品版本的 "Team Foundation Server" 窗格的屏幕截图。

  2. 它们通过指定项目集合的 URL 来运行该工具以执行验证,如以下命令中所示:They run the tool to perform the validation by specifying the URL of the project collection, as shown in the following command:

    TfsMigrator validate /collection:http://contosotfs:8080/tfs/ContosoDev

    该工具显示一个错误。The tool shows an error.

    Team Foundation Server 迁移工具中的验证错误的屏幕截图。

  3. 它们会在工具位置之前找到文件夹中的日志文件 LogsThey locate the log files in the Logs folder, just before the tool location. 对于每个主要验证都会生成一个日志文件。A log file is generated for each major validation. TfsMigration.log 包含主要信息。TfsMigration.log holds the main information.

    Team Foundation Server 中的日志文件位置的屏幕截图。

  4. 它们找到了与标识相关的条目。They find this entry, which is related to identity.


  5. 它们会 TfsMigrator validate /help 在命令行运行,并可看到 /tenantDomainName 验证标识所需的命令。They run TfsMigrator validate /help at the command line, and they see that the command /tenantDomainName seems to be required to validate identities.


  6. 它们再次运行验证命令,并包括此值及其 Azure AD 名称 TfsMigrator validate /collection:http://contosotfs:8080/tfs/ContosoDev /tenantDomainName:contosomigration.onmicrosoft.comThey run the validation command again and include this value and their Azure AD name, TfsMigrator validate /collection:http://contosotfs:8080/tfs/ContosoDev /tenantDomainName:contosomigration.onmicrosoft.com.


  7. 在打开的 Azure AD 登录 "窗口中,他们将输入全局管理员用户的凭据。In the Azure AD sign-in window that opens, they enter the credentials of a global admin user.

    具有管理员凭据的 Azure AD 登录 "窗口的屏幕截图。

  8. 验证通过,并由工具确认。The validation passes and is confirmed by the tool.


步骤4:生成迁移文件Step 4: Build the migration files

完成验证后,Contoso 管理员可以使用 Team Foundation Server 迁移工具来构建迁移文件。With the validation complete, Contoso admins can use the Team Foundation Server migration tool to build the migration files.

  1. 它们会在工具中运行准备步骤。They run the preparation step in the tool.

    TfsMigrator prepare /collection:http://contosotfs:8080/tfs/ContosoDev /tenantDomainName:contosomigration.onmicrosoft.com /accountRegion:cus

    Team Foundation Server 迁移工具中的 "准备" 命令的屏幕截图。

    准备步骤执行以下操作:The preparation step does the following:

    • 扫描集合以查找所有用户的列表,然后 () 填充标识地图日志 IdentityMapLog.csvScans the collection to find a list of all users and then populates the identify map log (IdentityMapLog.csv).
    • 准备与 Azure AD 的连接,以便为每个标识找到匹配项。Prepares the connection to Azure AD to find a match for each identity.
    • Contoso 已经部署 Azure AD 并使用 Azure AD Connect 进行同步,因此 "准备" 命令应该能够找到匹配的标识并将其标记为 活动状态Contoso has already deployed Azure AD and synchronized it by using Azure AD Connect, so the prepare command should be able to find the matching identities and mark them as Active.
  2. 此时将显示一个 Azure AD 登录屏幕,管理员将输入全局管理员的凭据。An Azure AD sign-in screen appears, and the admins enter the credentials of a global admin.

    在 "用户" 文本框中键入管理员凭据的 Azure AD "签名" 屏幕屏幕截图。

  3. 准备完成,该工具会报告导入文件已成功生成。The preparation is completed, and the tool reports that the import files have been generated successfully.


  4. 管理员现在可以看到 IdentityMapLog.csv 文件和文件都已 import.json 在新文件夹中创建。The admins can now see that both the IdentityMapLog.csv file and the import.json file have been created in a new folder.


  5. import.json文件提供导入设置。The import.json file provides import settings. 它包含所需的组织名称、存储帐户详细信息等信息。It includes information such as the desired organization name, and storage account details. 大多数字段是自动填充的。Most of the fields are populated automatically. 某些字段需要用户输入。Some fields require user input. 管理员打开该文件,并添加要创建的 Azure DevOps Services 组织名称 contosodevmigrationThe admins open the file and add the Azure DevOps Services organization name to be created, contosodevmigration. 对于此名称,Contoso Azure DevOps Services URL 将为 contosodevmigration.visualstudio.comWith this name, the Contoso Azure DevOps Services URL will be contosodevmigration.visualstudio.com.

    显示 Azure DevOps Services 组织名称的屏幕截图。


    迁移开始之前,必须先创建组织。The organization must be created before the migration begins. 完成迁移后,可以对其进行更改。It can be changed after the migration is completed.

  6. 管理员查看标识日志映射文件,其中显示了在导入期间将进入 Azure DevOps Services 的帐户。The admins review the identity log map file, which shows the accounts that will be brought into Azure DevOps Services during the import.

    • 活动标识指的是在导入后将成为 Azure DevOps Services 中的用户的标识。Active identities refer to identities that will become users in Azure DevOps Services after the import.
    • 在 Azure DevOps Services 中,将在迁移后授权这些标识并将其显示为组织中的用户。In Azure DevOps Services, these identities will be licensed and displayed as users in the organization after migration.
    • 标识在文件中的 "预期导入状态" 列中标记为 "活动"。The identities are marked as Active in the Expected Import Status column in the file.

    标识日志映射文件的屏幕截图,显示要引入 Azure DevOps Services 的帐户。

步骤 5:迁移到 Azure DevOps ServicesStep 5: Migrate to Azure DevOps Services

完成准备工作后,Contoso 管理员可以重点关注迁移。With the preparation completed, Contoso admins can focus on the migration. 在运行迁移后,他们将使用 TFVC 切换到 Git 进行版本控制。After they run the migration, they'll switch from using TFVC to Git for version control.

在开始之前,管理员计划使用开发团队计划停机时间,以便可以将集合脱机以便进行迁移。Before they start, the admins schedule downtime with the dev team, so that they can plan to take the collection offline for migration.

下面是要执行的迁移过程:Here is the migration process they'll follow:

  1. 拆离集合。Detach the collection. 集合的标识数据位于 Team Foundation Server 实例的配置数据库中,而集合是附加和联机的。Identity data for the collection resides in the configuration database for the Team Foundation Server instance while the collection is attached and online.

    当集合与 Team Foundation Server 实例分离时,将生成该标识数据的副本,然后将其与集合进行打包以进行传输。When a collection is detached from the Team Foundation Server instance, a copy of that identity data is made and then packaged with the collection for transport. 如果没有此数据,将无法执行导入的标识部分。Without this data, the identity portion of the import can't be executed.

    建议在导入完成后将集合保持分离状态,因为在导入过程中发生的更改无法导入。We recommended that the collection stay detached until the import has been completed, because changes that occur during the import can't be imported.

  2. 生成备份。Generate a backup. 下一步是生成可导入到 Azure DevOps Services 中的备份。The next step is to generate a backup that can be imported into Azure DevOps Services. 数据层应用程序组件包 (DACPAC) 是一项 SQL Server 功能,它允许将数据库更改打包到一个文件中,然后将其部署到其他 SQL 实例。The data-tier application component package (DACPAC) is a SQL Server feature that allows database changes to be packaged into a single file and then deployed to other instances of SQL.

    还可以将备份直接还原到 Azure DevOps Services,并将其用作将收集数据获取到云的打包方法。The backup can also be restored directly to Azure DevOps Services, and it's used as the packaging method for getting collection data to the cloud. Contoso 将使用该 sqlpackage.exe 工具生成 DACPAC。Contoso will use the sqlpackage.exe tool to generate the DACPAC. 此工具包含在 SQL Server Data Tools 中。This tool is included in SQL Server Data Tools.

  3. 上传到存储。Upload to storage. 创建 DACPAC 后,管理员将其上传到 Azure 存储。After the DACPAC is created, the admins upload it to Azure Storage. 将其上传后,它们会获得 (SAS) 的共享访问签名,以允许 Team Foundation Server 迁移工具访问存储。After they've uploaded it, they get a shared access signature (SAS) to allow the Team Foundation Server migration tool access to the storage.

  4. 填写导入文件。Fill out the import. 然后,Contoso 可以在导入文件中完成缺少的字段,包括 DACPAC 设置。Contoso can then complete the missing fields in the import file, including the DACPAC setting. 为了确保在完整迁移之前一切都正常工作,管理员将指定他们要执行 模拟运行 导入。To ensure that everything's working properly before the full migration, the admins will specify that they want to perform a dry-run import.

  5. 执行模拟导入。Perform a dry-run import. 模拟导入有助于测试集合迁移。A dry-run import helps them test the collection migration. 晾干的运行寿命有限,因此在生产迁移运行之前将其删除。Dry runs have a limited life, so they're deleted before a production migration runs. 它们会在设置的持续时间后自动删除。They're deleted automatically after a set duration. 在导入完成后发送的成功电子邮件中包含一条通知 Contoso,将删除该干布。A note that informs Contoso when the dry run will be deleted is included in the success email that's sent after the import finishes. 团队会相应地记录和计划。The team takes note and plans accordingly.

  6. 完成生产迁移。Complete the production migration. 完成模拟迁移后,Contoso 管理员将通过更新 import.json 文件并再次运行导入来执行最终迁移。With the dry-run migration completed, Contoso admins do the final migration by updating the import.json file and then running import again.

分离集合Detach the collection

在分离集合之前,Contoso 管理员会对 Team Foundation Server 实例执行本地 SQL Server 实例备份和 VMware 快照。Before they detach the collection, Contoso admins take a local SQL Server instance backup and a VMware snapshot of the Team Foundation Server instance.

  1. 在 Team Foundation Server 管理控制台中,管理员选择要分离的集合 ContosoDevIn the Team Foundation Server Administration Console, the admins select the collection they want to detach, ContosoDev.

    Foundation Server 管理控制台的 "团队项目集合" 部分的屏幕截图。

  2. 它们选择 " 常规 " 选项卡,然后选择 " 分离集合"。They select the General tab and then select Detach Collection.

    Foundation Server 管理控制台中的 "分离集合" 链接的屏幕截图。

  3. 在 " 分离团队项目集合 向导" 的 " 维护消息 " 窗格上,管理员为可能尝试连接到集合中的项目的用户提供一条消息。In the Detach Team Project Collection wizard, on the Servicing Message pane, the admins provide a message for users who might try to connect to projects in the collection.

    分离团队项目集合向导中的 "维护消息" 窗格的屏幕截图。

  4. 在 " 分离进度 " 窗格上,它们监视进度。On the Detach Progress pane, they monitor progress. 进程完成后,选择 " 下一步"。When the process finishes, they select Next.

    分离团队项目集合向导中的 "分离进度 * *" 窗格的屏幕截图。

  5. 在 " 就绪检查 " 窗格上,当检查完成时,它们会选择 " 分离"。On the Readiness Checks pane, when the checks finish, they select Detach.

    分离团队项目集合向导中的 "就绪检查" 窗格的屏幕截图。

  6. 成功分离集合后,它们会选择 " 关闭 " 以完成操作。When the collection has been successfully detached, they select Close to finish up.

    分离团队项目集合向导中的 "完成" 窗格的屏幕截图。

    Team Foundation Server 管理控制台中不再引用该集合。The collection is no longer referenced in the Team Foundation Server Administration Console.

    Team Foundation Server 管理控制台的屏幕截图,显示集合不再列出。

生成 DACPACGenerate a DACPAC

Contoso 管理员创建要导入 Azure DevOps Services 的备份或 DACPAC。Contoso admins create a backup, or DACPAC, to import into Azure DevOps Services.

  • 管理员使用 sqlpackage.exe SQL Server Data Tools (SSDT) 中的实用工具来创建 DACPAC。The admins use the sqlpackage.exe utility in SQL Server Data Tools (SSDT) to create the DACPAC. SQL Server Data Tools 安装了多个版本 sqlpackage.exe ,并且它们位于名称如下的文件夹下 120 130 140There are multiple versions of sqlpackage.exe installed with SQL Server Data Tools, and they're located under folders with names like 120, 130, and 140. 请务必使用正确的版本来准备 DACPAC。It's important to use the right version to prepare the DACPAC.

  • Team Foundation Server 2018 sqlpackage.exe140 文件夹中导入需要使用或更高版本。Team Foundation Server 2018 imports need to use sqlpackage.exe from the 140 folder or higher. 对于 CONTOSOTFS ,此文件位于中 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140For CONTOSOTFS, this file is located in C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140.

Contoso 管理员生成 DACPAC,如下所示:Contoso admins generate the DACPAC as follows:

  1. 它们将打开一个命令提示符,并中转到该 sqlpackage.exe 位置。They open a command prompt and go to the sqlpackage.exe location. 若要生成 DACPAC,请运行以下命令:To generate the DACPAC, they run the following command:

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

    命令提示符屏幕截图,显示用于生成 DACPAC 的命令。

    将显示以下消息:The following message is displayed:

    命令提示符屏幕截图,显示一条消息,指出已成功将数据库提取并保存到 DACPAC 文件。

  2. 它们验证 DACPAC 文件的属性。They verify the properties of the DACPAC file.

    显示用于验证的 DACPAC 文件属性的屏幕截图。

将文件上传到存储Upload the file to storage

管理员创建 DACPAC 文件后,会将其上传到 Azure 存储帐户。After the admins create the DACPAC file, they upload it to the Azure Storage account.

  1. 它们下载并安装 Azure 存储资源管理器They download and install Azure Storage Explorer.

    * * 下载存储资源管理器免费版。 * *

  2. 在存储资源管理器中,管理员连接到其订阅,然后搜索并选择为迁移 () 创建的存储帐户 contosodevmigrationIn Storage Explorer, the admins connect to their subscription and then search for and select the storage account they created for the migration (contosodevmigration). 它们创建新的 blob 容器 azuredevopsmigrationThey create a new blob container, azuredevopsmigration.

    存储资源管理器中的 "创建 Blob 容器" 链接的屏幕截图。

  3. 在 " 上载文件 " 窗格的 " Blob 类型 " 下拉列表中,管理员指定 DACPAC 文件上传的 块 BlobOn the Upload files pane, in the Blob type drop-down list, the admins specify Block Blob for the DACPAC file upload.

    存储资源管理器中的 "上传文件" 窗格的屏幕截图。

  4. 文件上传后,选择文件名,然后选择 " 生成 SAS"。After they upload the file, they select the file name and then select Generate SAS. 它们展开存储帐户下的 " Blob 容器 " 列表,选择包含导入文件的容器,然后选择 " 获取共享访问签名"。They expand the Blob Containers list under the storage account, select the container with the import files, and then select Get Shared Access Signature.

    存储资源管理器中的 "获取共享访问签名" 链接的屏幕截图。

  5. 在 " 共享访问签名 " 窗格上,接受默认设置,然后选择 " 创建"。On the Shared Access Signature pane, they accept the default settings and then select Create. 这会将访问权限启用 24 小时。This enables access for 24 hours.

    存储资源管理器中的 "共享访问签名" 窗格的屏幕截图。

  6. 它们复制共享访问签名 URL,以便 Team Foundation Server 迁移工具可以使用它。They copy the shared access signature URL, so that it can be used by the Team Foundation Server migration tool.

    存储资源管理器中的共享访问签名的 URL 的屏幕截图。


必须在允许的时间范围内执行迁移,否则权限将过期。The migration must happen within the allowed time window or the permissions will expire. 不要 从 Azure 门户生成 SAS 密钥。Do not generate an SAS key from the Azure portal. 从门户生成的密钥是帐户范围的,不能与导入一起使用。Keys that are generated from the portal are account-scoped and won't work with the import.

填写导入设置Fill in the import settings

之前,Contoso 管理员部分填充了导入规范文件 import.jsonEarlier, Contoso admins partially filled in the import specification file, import.json. 现在,他们需要添加剩余的设置。Now, they need to add the remaining settings.

它们打开该 import.json 文件并完成以下字段:They open the import.json file and complete the following fields:

  • 位置: 它们输入以前生成的 SAS 密钥的位置。Location: They enter the location of the SAS key that was generated previously.
  • DACPAC: 它们输入其之前上传到存储帐户的 DACPAC 文件的名称,并确保包括 .dacpac 扩展名。DACPAC: They enter the name of the DACPAC file that they uploaded earlier to the storage account, making sure to include the .dacpac extension.
  • ImportType: 它们现在输入 DryRunImportType: They enter DryRun for now.

已填充字段的 "import.js" 文件的屏幕截图。

执行模拟迁移Perform a dry-run migration

Contoso 管理员执行模拟的迁移,确保一切按预期运行。Contoso admins perform a dry-run migration to make sure that everything's working as expected.

  1. 它们将打开一个命令提示符,然后前往 TfsMigrator () 位置 C:\TFSMigratorThey open a command prompt and then go to the TfsMigrator location (C:\TFSMigrator).

  2. 他们希望确保文件的格式正确,并且 SAS 密钥正常工作。They want to make sure that the file is formatted properly and that the SAS key is working. 它们通过运行以下命令验证导入文件:They validate the import file by running the following command:

    TfsMigrator import /importFile:C:\TFSMigrator\import.json /validateonly

    验证将返回一个错误,指出 SAS 密钥在过期之前需要更长的时间。The validation returns an error saying that the SAS key needs a longer period before it expires.


  3. 它们使用 Azure 存储资源管理器创建新的 SAS 密钥,该密钥的过期时间设置为七天。They use Azure Storage Explorer to create a new SAS key with the period before expiration set to seven days.

    显示过期日期的存储资源管理器 "共享访问签名" 窗格的屏幕截图。

  4. 它们更新 import.json 文件并重新运行该命令。They update the import.json file and rerun the command. 这次,验证已成功完成。This time, the validation is completed successfully.

    TfsMigrator import /importFile:C:\TFSMigrator\import.json /validateonly

    显示 * * 验证已成功完成的命令提示屏幕截图 * * 消息。

  5. 它们通过运行以下命令来启动干燥运行:They start the dry run by running the following command:

    TfsMigrator import /importFile:C:\TFSMigrator\import.json

    系统会显示一条消息,要求用户确认是否要继续迁移。A message is displayed asking them to confirm that they want to continue with the migration. 请注意,在该过程中,将在其上维护暂存数据的七天期限。Note the seven-day period after the dry run during which the staged data will be maintained.

    要求 Contoso 确认是否要继续迁移的消息的屏幕截图。

  6. 此时将打开 Azure AD 登录 "窗口。The Azure AD sign-in window opens. Contoso 管理员通过管理员权限登录到 Azure AD。Contoso admins sign in to Azure AD with admin permissions.

    Visual Studio 中 Azure AD 登录 "窗口的屏幕截图。

    将显示一条消息,确认导入已成功启动。A message is displayed confirming that the import has been started successfully.


  7. 大约15分钟后,管理员会访问网站并查看以下信息:After about 15 minutes, the admins go to the website and see the following information:


  8. 迁移完成后,Contoso 开发人员负责人会登录到 Azure DevOps Services,以确保干燥运行正常运行。After the migration finishes, a Contoso dev lead signs in to Azure DevOps Services to ensure that the dry run worked properly. 完成身份验证后,Azure DevOps Services 需要一些详细信息用于确认组织。After authentication, Azure DevOps Services needs a few details to confirm the organization.

    向 Contoso 团队请求其他信息的 Azure DevOps Services 窗口的屏幕截图。

    开发人员主管可以看到这些项目已成功迁移。The dev lead can see that the projects have been migrated successfully. 页面顶部附近的通知会警告您将在15天内删除该干布。A notice near the top of the page warns that the dry run account will be deleted in 15 days.

    Azure DevOps Services 界面的屏幕截图,并出现一条消息,警告您将在15天内删除该干布。

  9. 开发组长会打开其中一个项目,然后选择 " > 分配给我 的工作项"。The dev lead opens one of the projects and then selects Work Items > Assigned to me. 此页验证是否已成功迁移工作项数据以及标识。This page verifies that the work item data has been migrated successfully, along with the identity.

    Azure DevOps Services "工作项" 窗格的屏幕截图,其中显示所有已迁移的项目。

  10. 为了确认已迁移源代码和历史记录,开发组长检查其他项目和代码。To confirm that the source code and history have been migrated, the dev lead checks other projects and code.

    Azure DevOps Services "历史记录" 窗格的屏幕截图,显示所有代码和历史记录均已迁移。

运行生产迁移Run the production migration

完成此模拟后,Contoso 管理员将继续执行生产迁移。Now that the dry run is complete, Contoso admins move on to the production migration. 他们删除试运行,更新导入设置,并再次运行导入。They delete the dry run, update the import settings, and run import again.

  1. 在 Azure DevOps Services 门户中,他们将删除模拟运行的组织。In the Azure DevOps Services portal, they delete the dry-run organization.

  2. 它们更新 import.json 文件以将 ImportType 设置为 ProductionRunThey update the import.json file to set the ImportType to ProductionRun.

    Azure DevOps Services 门户的屏幕截图,ImportType 字段设置为 ProductionRun。

  3. 与晾干运行时一样,它们通过运行以下命令开始迁移:As they did for the dry run, they start the migration by running the following command:

    TfsMigrator import /importFile:C:\TFSMigrator\import.json.TfsMigrator import /importFile:C:\TFSMigrator\import.json.

    将显示一条消息,要求管理员确认迁移。A message is displayed asking the admins to confirm the migration. 它警告将数据保存在一个安全的位置,最长可为7天。It warns that data could be held in a secure location as a staging area for up to seven days.

    Azure DevOps Services 消息屏幕截图,警告已迁移的数据最多可保存7天。

  4. 在 Azure AD 登录 "窗口中,他们指定 Contoso 管理员登录。In the Azure AD sign-in window, they specify a Contoso admin sign-in.

    Visual Studio 中 Azure AD 登录屏幕的屏幕截图。

    将显示一条消息,表明导入已成功启动。A message is displayed that the import has started successfully.

    已成功启动导入的 Azure DevOps Services 消息的屏幕截图。

  5. 大约15分钟后,管理员会访问网站并查看以下信息:After about 15 minutes, the admins go to the website and see the following information:


  6. 迁移完成后,开发组长会登录 Azure DevOps Services,以确保迁移正常工作。After the migration finishes, a dev lead signs into Azure DevOps Services to ensure that the migration worked properly. 登录后,开发人员主管可以看到项目已迁移。After signing in, the dev lead can see that projects have been migrated.


  7. 开发组长会打开一个项目,并选择 " > 分配给我 的工作项"。The dev lead opens one of the projects and selects Work Items > Assigned to me. 这表明工作项数据已迁移,以及标识。This shows that the work item data has been migrated, along with the identity.


  8. 开发线索检查以确认已迁移其他工作项数据。The dev lead checks to confirm that other work item data has been migrated.


  9. 为了确认已迁移源代码和历史记录,开发组长检查其他项目和代码。To confirm that the source code and history have been migrated, the dev lead checks other projects and code.


将源控件从 TFVC 移至 GitMove source control from TFVC to Git

迁移现在完成后,Contoso 管理员希望将源代码管理从 TFVC 移至 Git。With the migration now completed, Contoso admins want to move source code management from TFVC to Git. 管理员需要将当前位于其 Azure DevOps Services 组织中的源代码导入为同一组织中的 Git 存储库。The admins need to import the source code that's currently in their Azure DevOps Services organization as Git repos in the same organization.

  1. 在 Azure DevOps Services 门户中,他们打开一个 TFVC 存储库, $/PolicyConnect 并查看它。In the Azure DevOps Services portal, they open one of the TFVC repos, $/PolicyConnect, and review it.

    Azure DevOps Services 门户中的 * * $/PolicyConnect * * 存储库的屏幕截图。

  2. 在 "源 $/PolicyConnect " 下拉列表中,选择 " 导入存储库"。In the source $/PolicyConnect drop-down list, they select Import repository.

    Azure DevOps Services 门户中的 "导入存储库" 链接的屏幕截图。

  3. 在 " 源类型 " 下拉列表中,选择 " TFVC"。In the Source type drop-down list, they select TFVC. 在 " 路径 " 框中,指定存储库的路径,然后选择 " 导入"。In the Path box, they specify the path to the repo, and then select Import. 它们决定将 " 迁移历史记录 " 复选框保留为未选中状态。They decide to leave the Migrate History check box cleared.

    "从 TFVC 导入" 窗格的屏幕截图。


    由于 TFVC 和 Git 存储版本控制信息的方式不同,因此我们建议 Contoso 不要 迁移其存储库历史记录。Because TFVC and Git store version control information differently, we recommend that Contoso not migrate its repository history. 当我们将 Windows 和其他产品从集中式版本控制迁移到 Git 时,Microsoft 会采取这种方法。This is the approach that Microsoft took when we migrated Windows and other products from centralized version control to Git.

  4. 导入完成后,管理员检查代码。After the import finishes, the admins review the code.


  5. 它们为第二个存储库重复此过程 $/smarthotelcontainerThey repeat the process for the second repository, $/smarthotelcontainer.

    第二个存储库的 * * 从 TFVC 导入 * * 窗格的屏幕截图。

  6. 开发人员领导检查源后,即表示已完成迁移到 Azure DevOps Services。After the dev lead reviews the source, they agree that the migration to Azure DevOps Services is done. 现在 Azure DevOps Services 成为迁移中所涉及的团队内所有开发的源。Azure DevOps Services now becomes the source for all development within the teams involved in the migration.

    显示迁移到 Azure DevOps Services 的屏幕截图已完成。

需要更多帮助?Need more help?

有关详细信息,请参阅 将存储库从 TFVC 导入到 GitFor more information, see Import repositories from TFVC to Git.

迁移后的清理Clean up after migration

迁移现在完成后,Contoso 团队需要执行以下操作:With the migration now complete, the Contoso team needs to do the following:

  • 查看导入后一文来了解有关更多导入活动的信息。Review the post-import article for information about additional import activities.
  • 删除 TFVC 存储库或将其置于只读模式。Either delete the TFVC repos or place them in read-only mode. 不得使用基本代码,但可以对其历史记录进行引用。The code bases must not be used, but they can be referenced for their history.

迁移后操作培训Post-migration training

Contoso 团队需要为相关的团队成员提供 Azure DevOps Services 和 Git 培训。The Contoso team will need to provide Azure DevOps Services and Git training for relevant team members.