Skip to main content

阶段 4. 准备从 Azure DevOps 迁移到 GitHub

通过了解时间线、迁移的数据以及组织结构来规划迁移。

确定需要迁移的内容量

确定时间线,这将在很大程度上决定你的方法。 若要确定时间线,第一步是获取需迁移内容的清单。

  • 存储库数目
  • 拉取请求数

注意

迁移时间主要基于存储库中的拉取请求数。 如果要迁移 1,000 个存储库,并且每个存储库平均有 100 个拉取请求,则迁移速度可能会非常快。 如果只想迁移 100 个存储库,但每个存储库平均有 75,000 个拉取请求,迁移需要更长的时间,并且需要更多的规划和测试。

我们建议使用 ADO2GH extension of the GitHub CLI 中的 inventory-report 命令。 此命令将连接到 Azure DevOps API,然后创建多个 CSV 文件。 repos.csv 包含有关存储库的信息,包括拉取请求数。

若要生成 CSV 文件,请使用以下命令,并将 YOUR_ADO_ORG 替换为您在 Azure DevOps 上的组织名称。

Shell
gh ado2gh inventory-report --ado-org YOUR_ADO_ORG

获取需要迁移的存储库清单后,根据所需的时间线权衡清单数据。

  • 如果组织能够承受更高程度的更改,则可以一次性迁移所有存储库,在几天内完成迁移工作。
  • 如果你的团队无法同时迁移,可能需要分批并错开迁移时间以适应团队的时间表,从而延长迁移工作周期。

确定 GitHub 组织结构

接下来,计划将在 GitHub 中创建的组织结构。 ADO 和 GitHub 组织企业工作的方式不同。

  • ADO:组织>团队项目>存储库
  • GitHub:企业>组织>存储库

迁移到 GitHub 后,应只有一个企业帐户和该企业拥有的少量组织。 ADO 中的每个组织都应对应 GitHub 上的单个组织。

注意

在 ADO 中用来为存储库分组的团队项目概念在 GitHub 中不适用。 不建议在 GitHub 上为 ADO 上的每个团队项目创建组织,因为这可能会在每个组织中生成未分组存储库的大型列表。 但你可以创建团队来管理对存储库组的访问。

如果要将迁移工作分解成批,新结构可以帮助你确定它们。 如果 ADO 中有多个组织,并且每个组织的存储库都是合理大小的批次,请考虑按组织进行批处理。

  1. 决定新组织结构。
  2. 决定是否需要将迁移工作分解成更小的批次。
  3. 如果需要,请决定要如何分解迁移。

配置存储库权限

由于 GitHub 中权限的使用方式与在 ADO 中的不同,因此 GitHub Enterprise Importer 不会尝试从 ADO 迁移存储库权限。

使用 ADO2GH CLI 时,GitHub Enterprise Importer 会为 ADO 中的每个团队项目在 GitHub 中创建两个团队。 每个团队被授予面向所有源自团队项目的存储库的不同级别的访问权限。

团队对已迁移的存储库的访问
团队-项目-维护者维护者
TEAM-PROJECT-管理员管理员

若要授予面向迁移存储库的访问权限,可以将人员添加到这些团队。 可以在 GitHub 上手动执行此操作,也可以选择在迁移过程中将团队链接到 Azure Active Directory (AAD) 组,即可在 AAD 中管理组成员身份。 有关手动管理团队成员身份的详细信息,请参阅 添加组织成员到团队

后续步骤

在下一阶段,你将执行试运行,然后迁移存储库。 请参阅“阶段 5. 将存储库从 Azure DevOps 迁移到 Github”。