跳至主要内容

将存储库从 Azure DevOps 迁移到 GitHub Enterprise Cloud

你可以使用 GitHub CLI 或 GraphQL API 将存储库从 Azure DevOps 迁移到 GitHub Enterprise Cloud。

工具导航

关于使用 GitHub Enterprise Importer 进行存储库迁移

你可以使用 GitHub CLI 或 API 运行迁移。

GitHub CLI 简化了迁移流程,建议大多数客户使用。有大量定制需求的高级客户可以使用 API 与 GitHub Enterprise Importer 构建自己的集成。

要查看有关使用 API 的说明,请使用页面顶部的工具切换器。
要查看有关使用 GitHub CLI 的说明,请使用页面顶部的工具切换器。

先决条件

  • 我们强烈建议你执行迁移试运行,并在不久后完成生产迁移。要详细了解试运行,请参阅“Azure DevOps 到 GitHub Enterprise Cloud 迁移概述”。
  • 确保你了解将要迁移的数据以及 Importer 的已知支持限制。有关更多信息,请参阅“Azure DevOps 到 GitHub Enterprise Cloud 迁移概述”。
  • 虽然不是必需的,但我们建议你在生产迁移期间停止工作。Importer 不支持增量迁移,因此在迁移期间发生的任何更改都不会迁移。如果你选择在生产迁移期间不停止工作,则需要手动迁移这些更改。
  • 对于 GitHub.com 上的目标组织,你需要成为组织所有者或拥有迁移者角色。有关迁移者角色的更多信息,请参阅“管理 Azure DevOps 迁移的访问权限”。

步骤 0:准备使用 GitHub GraphQL API

要进行 GraphQL 查询,你需要编写自己的脚本或使用 HTTP 客户端,如 Insomnia

要详细了解如何开始使用 GitHub GraphQL API,包括如何进行身份验证,请参阅“使用 GraphQL 形成调用”。

步骤 1:获取迁移目标的 ownerId

作为 GitHub Enterprise Cloud 中的组织所有者,请使用 GetOrgInfo 查询来返回 ownerId,也称为组织 ID,用于你希望拥有已迁移存储库的组织。你需要 ownerId 来识别你的迁移目标。

GetOrgInfo 查询

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}
查询变量说明
login你的组织名称。

GetOrgInfo 响应

{
  "data": {
    "organization": {
      "login": "Octo",
      "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
      "name": "Octo-org",
      "databaseId": 5610
    }
  }
}

在此示例中,MDEyOk9yZ2FuaXphdGlvbjU2MTA= 是组织 ID 或 ownerId,我们将在下一步中使用它。

步骤 2:确定你的迁移来源

你可以使用 createMigrationSource 查询设置迁移源。你需要提供从 GetOrgInfo 查询中收集的 ownerId 或组织 ID。

你的迁移源是你的 ADO 组织。

createMigrationSource 突变

mutation createMigrationSource($name: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: "https://dev.azure.com", ownerId: $ownerId, type: AZURE_DEVOPS}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

注意:请确保对 type 使用 AZURE_DEVOPS

查询变量说明
name你的迁移源的名称。此名称仅供你参考,因此你可以使用任何字符串。
ownerId你在 GitHub Enterprise Cloud 中的组织的组织 ID。

createMigrationSource 响应

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
        "name": "Azure Devops Source",
        "url": "https://dev.azure.com",
        "type": "AZURE_DEVOPS"
      }
    }
  }
}

在此示例中,MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA 是迁移源 ID,我们将在下一步中使用它。

步骤 3:开始你的存储库迁移

当你开始迁移时,单个存储库及其随附的数据将迁移到一个你确定的全新 GitHub 存储库中。

如果您想从同一源组织一次性移动多个存储库,您可以排队进行多次迁移。您可以同时运行最多 5 次存储库迁移。

startRepositoryMigration 突变

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $sourceRepositoryUrl: URI!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility
    sourceRepositoryUrl: $sourceRepositoryUrl,
  }) {
    repositoryMigration {
      id
      migrationSource {
        id
        name
        type
      }
      sourceUrl
    }
  }
}
查询变量说明
sourceIdcreateMigrationSource 突变返回的迁移源 id
ownerId你在 GitHub Enterprise Cloud 中的组织的组织 ID。
repositoryName一个自定义的唯一存储库名称,目前未被 GitHub Enterprise Cloud 上组织拥有的任何存储库使用。当迁移完成或停止时,将在该存储库中创建一个错误日志问题。
continueOnError迁移设置,允许迁移在遇到不会导致迁移失败的错误时继续进行。必须为 truefalse。我们强烈建议将 continueOnError 设置为 true,以便您的迁移继续进行,除非导入器无法移动 Git 源或导入器失去连接且无法重新连接以完成迁移。
githubPatGitHub Enterprise Cloud 上目标组织的个人访问令牌。
accessToken源的个人访问令牌。
targetRepoVisibility新存储库的可见性。必须为 privatepublicinternal。如果未设置,您的存储库将以私有方式迁移。
sourceRepositoryUrl源存储库的 URL,使用格式 https://dev.azure.com/{organization}/_git/{repository}

有关个人访问令牌要求,请参阅“管理 Azure DevOps 迁移的访问权限”。

在下一步中,您将使用从 startRepositoryMigration 突变返回的迁移 ID 来检查迁移状态。

步骤 4:检查迁移状态

为了检测任何迁移故障并确保您的迁移正常工作,您可以使用 getMigration 查询检查您的迁移状态。您还可以使用 getMigrations 检查多个迁移的状态。

getMigration 查询将返回一个状态,让你知道迁移是 queuedin progressfailed 还是 completed。如果迁移失败,Importer 将提供失败原因。

getMigration 查询

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}
查询变量说明
ididstartRepositoryMigration 变异 返回的迁移的 id

步骤 5:验证迁移并检查错误日志

为了完成迁移,我们建议你检查“迁移日志”问题。此问题在目标存储库的 GitHub 中创建。

Screenshot of an issue with the title "Migration Log." The second comment in the issue includes logs for a migration.

最后,我们建议你查看已迁移的存储库以进行健全性检查。

步骤 1:安装 GitHub CLI 的 ADO2GH 扩展

如果这是你的第一次迁移,你需要安装 GitHub CLI 的 ADO2GH 扩展。有关 GitHub CLI 的更多信息,请参阅“关于 GitHub CLI”。

或者,你可以从 github/gh-ado2gh 存储库的 发布页面 下载独立二进制文件。你可以直接运行此二进制文件,而无需 gh 前缀。

  1. 安装 GitHub CLI。有关 GitHub CLI 的安装说明,请参阅 GitHub CLI 存储库

    注意:你需要 GitHub CLI 版本 2.4.0 或更高版本。你可以使用 gh --version 命令检查已安装的版本。

  2. 安装 ADO2GH 扩展。

    Shell
    gh extension install github/gh-ado2gh
    

任何时候你需要 ADO2GH 扩展的帮助,你都可以使用 --help 标志和命令。例如,gh ado2gh --help 将列出所有可用的命令,gh ado2gh migrate-repo --help 将列出 migrate-repo 命令的所有可用选项。

步骤 2:更新 GitHub CLI 的 ADO2GH 扩展

GitHub CLI 的 ADO2GH 扩展每周更新。为了确保你使用的是最新版本,请更新扩展。

Shell
gh extension upgrade github/gh-ado2gh

步骤 3:设置环境变量

在使用 ADO2GH 扩展迁移到 GitHub Enterprise Cloud 之前,你必须创建可以访问源组织和目标组织的个人访问令牌,然后将个人访问令牌设置为环境变量。

  1. 创建并记录一个个人访问令牌(经典),该令牌将对 GitHub Enterprise Cloud 上的目标组织进行身份验证,确保令牌满足所有要求。有关详细信息,请参阅“管理 Azure DevOps 迁移的访问权限”。

  2. 创建并记录一个个人访问令牌,该令牌将对 Azure DevOps 上的源组织进行身份验证,确保此令牌满足所有要求。有关详细信息,请参阅“管理 Azure DevOps 迁移的访问权限”。

  3. 为个人访问令牌设置环境变量,将以下命令中的 TOKEN 替换为您上面记录的个人访问令牌。对目标组织使用 GH_PAT,对源组织使用 ADO_PAT

    • 如果您使用的是终端,请使用 export 命令。

      Shell
      export GH_PAT="TOKEN"
      export ADO_PAT="TOKEN"
      
    • 如果您使用的是 PowerShell,请使用 $env 命令。

      Shell
      $env:GH_PAT="TOKEN"
      $env:ADO_PAT="TOKEN"
      

步骤 4:生成迁移脚本

如果您想一次性将多个存储库迁移到 GitHub Enterprise Cloud,请使用 GitHub CLI 生成迁移脚本。生成的脚本将包含一个迁移命令列表,每个存储库一个命令。

注意:生成脚本会输出一个 PowerShell 脚本。如果您使用的是终端,您需要使用 .ps1 文件扩展名输出脚本,并为 MacLinux 安装 PowerShell 才能运行它。

如果您想迁移单个存储库,请跳到下一步。

生成迁移脚本

要生成迁移脚本,请运行 gh ado2gh generate-script 命令。

Shell
gh ado2gh generate-script --ado-org SOURCE --github-org DESTINATION --output FILENAME

若要为脚本添加其他功能,例如重新连接管道、创建团队和配置 Azure Boards 集成,可以添加 --all 标志。

如果希望脚本下载每个已迁移存储库的迁移日志,请添加 --download-migration-logs 标志。有关迁移日志的详细信息,请参阅“访问 GitHub Enterprise Importer 的迁移日志”。

将上述命令中的占位符替换为以下值。

占位符
SOURCE源组织名称
DESTINATION目标组织名称
FILENAME生成迁移脚本的文件名

如果使用终端,请使用 .ps1 文件扩展名,因为生成的脚本需要 PowerShell 才能运行。可以为 MacLinux 安装 PowerShell。

审阅迁移脚本

生成脚本后,审阅该文件并根据需要编辑该脚本。

  • 如果有任何不想迁移的存储库,请删除或注释掉相应的行。
  • 如果希望任何存储库在目标组织中具有不同的名称,请更新相应 --target-repo 标志的值。

如果将 ADO2GH 下载为独立二进制文件,而不是作为 GitHub CLI 的扩展,则需要更新生成的脚本以运行二进制文件,而不是 gh ado2gh

步骤 5:迁移存储库

可以使用迁移脚本迁移多个存储库,也可以使用 gh ado2gh migrate-repo 命令迁移单个存储库。

迁移多个存储库

若要迁移多个存储库,请运行上面生成的脚本。将以下命令中的 FILENAME 替换为生成脚本时提供的文件名。

  • 如果使用终端,请使用 ./

    Shell
    ./FILENAME
    
  • 如果使用 PowerShell,请使用 .\

    Shell
    .\FILENAME
    

迁移单个存储库

若要迁移单个存储库,请使用 gh ado2gh migrate-repo 命令。

Shell
gh ado2gh migrate-repo --ado-org SOURCE --ado-team-project TEAM-PROJECT --ado-repo CURRENT-NAME --github-org DESTINATION --github-repo NEW-NAME

将上述命令中的占位符替换为以下值。

占位符
SOURCE源组织名称
CURRENT-NAME要迁移的存储库的名称
DESTINATION目标组织名称
NEW-NAME希望已迁移存储库具有的名称
团队项目要迁移的存储库的团队项目名称

如果您要取消迁移,请使用 abort-migration 命令,并将 MIGRATION-ID 替换为从 migrate-repo 返回的 ID。

Shell
gh ado2gh abort-migration --migration-id MIGRATION-ID

步骤 6:验证迁移并检查错误日志

迁移完成后,我们建议您查看迁移日志。有关更多信息,请参阅“访问 GitHub Enterprise Importer 的迁移日志”。

我们建议您检查已迁移存储库的健全性。