如何从AzDevops Server迁移至AzDevops Service现有组织

迁移前准备 #

• 确认本地AzDevOps Server版本不低于2019 Update 1，低于该版本需要先升级本地Server再做迁移
• 确认你拥有本地AzDevOps Server的项目集合管理员权限，以及目标AzDevOps Service组织的组织所有者/项目集合管理员权限
• 提前统计要迁移的资源清单，确认目标Service组织的配额足够（比如并行作业数、存储空间、用户数等）

各组件迁移方案 #

Repo（代码仓库） #

• 针对Git仓库：可通过Git远程推送完成迁移，先在Service端创建空仓库，本地拉取Server端仓库的所有分支和标签后执行如下命令：

  git remote add service <Service端仓库地址>
  git push --all service
  git push --tags service
  

  若仓库启用了LFS大文件存储，需提前安装Git LFS插件，追加执行git lfs push --all service完成大文件推送
• 针对TFVC仓库：如果需要保留完整变更历史，使用专用迁移工具导出导入；如果无需历史，可直接拉取最新代码提交到Service端对应仓库即可

Boards（工作项） #

• 迁移前先完成字段映射配置，将本地Server自定义的工作项字段、工作流状态和Service端项目的字段配置对齐，避免数据丢失
• 迁移顺序优先处理工作项，再迁移代码、流水线等其他资源，可保留工作项和代码提交、PR的关联关系
• 迁移后需要重新对齐Area路径、Iteration路径和Service端组织的层级结构

Pipeline（流水线） #

• 经典编辑器创建的流水线：直接在本地Server端导出JSON模板，到Service端对应项目导入即可，导入后需要重新配置服务连接（比如代码源、制品库、部署目标的连接），本地的服务连接无法在Service端直接复用
• YAML流水线：YAML文件默认存在代码仓库中，代码迁移完成后直接在Service端新建流水线，选择对应仓库的YAML文件即可，需要更新YAML中引用的服务连接名称、变量组、环境名称和Service端配置对齐
• 迁移前提前在Service端创建好依赖的变量组、安全凭据、部署环境等资源

Test Plan（测试计划） #

• 测试计划、测试用例、测试套件、共享步骤属于工作项范畴，可和Boards工作项一起迁移
• 测试运行历史、测试附件、自定义测试配置需要单独做迁移配置
• 测试用例关联的自动化流水线需要在流水线迁移完成后重新绑定，本地Server的构建ID和Service端ID不通用，原关联关系会失效

Artifacts（制品库） #

• 通用类型制品（NuGet、npm、Maven、PyPI等）：直接用对应包管理的命令批量推送即可，例如NuGet包推送命令为nuget push *.nupkg -Source <Service端制品源地址> -ApiKey <你的访问密钥>
• 流水线生成的一次性制品如果需要保留历史，可批量下载后上传到Service端，否则建议保留本地Server的存档即可，后续新生成的制品直接存储到Service端
• 迁移前提前开启Service端制品源的上传权限，配置好对应访问凭据

• Azure DevOps Migration Tools：官方推荐的开源迁移工具，支持批量迁移工作项、测试资源、流水线、Git仓库历史，支持自定义字段映射、关联关系保留，是全量迁移的首选工具
• az devops 命令行工具：Azure官方CLI工具，内置迁移相关的导出、导入命令，适合自动化批量处理中小项目的迁移
• TFVC Import Tool：微软官方推出的TFVC专用迁移工具，支持保留完整TFVC变更历史，可导入到Service端的TFVC或Git仓库
• 内置导出/导入功能：AzDevOps Server和Service原生支持流水线JSON导出导入、工作项Excel批量导出导入，少量资源迁移无需额外安装工具，直接使用原生功能即可

迁移注意事项 #

• 迁移前先完成本地AzDevOps Server的完整备份，避免操作失误丢失数据
• 先在Service端创建测试项目做试迁移，验证所有资源完整性、配置可用性之后再执行正式迁移
• 正式迁移前通知所有用户停掉本地Server的所有变更操作，避免迁移过程中产生的新数据丢失
• 迁移完成后做全量校验：检查代码分支标签是否完整、工作项关联关系是否正常、流水线可正常运行、测试用例完整、制品可正常拉取

内容的提问来源于stack exchange，提问作者user17396359