跳至主要内容

将存储库从 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 的迁移概述”。
  • 确保您了解将要迁移的数据以及导入程序已知的支持限制。有关详细信息,请参阅“关于从 Azure DevOps 迁移到 GitHub Enterprise Cloud”。
  • 虽然并非必需,但我们建议在生产迁移期间停止工作。导入程序不支持增量迁移,因此在迁移期间发生的任何更改都将不会迁移。如果您选择在生产迁移期间不停止工作,则需要手动迁移这些更改。
  • 对于 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

查询变量说明
名称迁移源的名称。此名称供您自己参考,因此您可以使用任何字符串。
所有者 ID您在 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
所有者 ID您在 GitHub Enterprise Cloud 上的组织的组织 ID。
repositoryNameGitHub Enterprise Cloud 上由组织拥有的任何存储库当前未使用的自定义唯一存储库名称。迁移完成后或停止后,将在该存储库中创建错误日志记录问题。
continueOnError迁移设置,允许在遇到不会导致迁移失败的错误时继续迁移。必须为 truefalse。我们强烈建议将 continueOnError 设置为 true,以便您的迁移继续进行,除非导入器无法移动 Git 源或导入器已断开连接且无法重新连接以完成迁移。
githubPat您在 GitHub Enterprise Cloud 上的目标组织的个人访问令牌。
accessToken您的源的个人访问令牌。
targetRepoVisibility新存储库的可见性。必须为 privatepublicinternal。如果没有设置,您的存储库将作为私有存储库进行迁移。
sourceRepositoryUrl使用格式 https://dev.azure.com/{organization}/_git/{repository} 的源代码存储库的 URL。

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

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

步骤 4:检查迁移状态

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

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

getMigration 查询

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}
查询变量说明
idid 是您迁移的 startRepositoryMigration 突变 返回的。

步骤 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 存储库

    注意:您需要 2.4.0 或更高版本的 GitHub CLI。您可以使用 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您希望迁移的存储库具有的名称
TEAM-PROJECT您要迁移的存储库的团队项目名称

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

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

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

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

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