如何将本地TFS实例中的扩展迁移至VSTS替代团队项目？

嘿，我来给你梳理几个经过实际验证的迁移方案，你可以根据自己扩展的复杂度和实际需求来选择：

方案一：手动导出+重新发布（适合小型/轻量扩展） #

• 导出本地扩展包：打开本地TFS的扩展管理面板，找到目标扩展，选择导出扩展包（通常是.vsix格式）。如果是你自己开发的扩展，直接用本地源码重新打包会更稳妥。
• 适配VSTS环境：检查扩展根目录的vss-extension.json配置文件，把targets字段调整为适配Azure DevOps Services（也就是原VSTS），确保publisher是你在VSTS平台注册的有效发布者账号，同时替换掉所有指向本地TFS的资源路径、API端点，统一改成VSTS的通用地址。
• 发布到目标项目：登录你的VSTS账号，进入市场管理中心，选择发布扩展，上传调整好的.vsix文件，按提示完成发布后，将扩展安装到指定的目标团队项目即可。

方案二：借助Azure DevOps工具链迁移（适合复杂/依赖多的扩展） #

如果你的扩展依赖了本地TFS的自定义工作项、字段或服务连接，官方工具链会更省心：

• 先同步扩展元数据：安装Azure CLI的DevOps扩展，运行az extension add --name azure-devops，登录VSTS账号az login后，用az devops extension create命令导入本地扩展的配置信息。
• 迁移关联依赖资源：用Azure DevOps Migration Tool处理自定义工作项模板、字段映射等依赖，把本地TFS的配置同步到VSTS的目标项目，确保扩展运行环境和本地一致。
• 测试后正式发布：在VSTS的测试项目先安装扩展，完整验证所有功能（尤其是权限、数据交互环节），确认没问题后再发布到正式团队项目。

方案三：源码迁移+流水线部署（适合自主开发的扩展） #

如果你是扩展的开发者，直接迁移源码并配置自动化部署会更便于后续维护：

• 迁移源码仓库：在VSTS目标项目创建新的Git仓库，把本地扩展的源码推送到这个仓库。
• 配置CI/CD流水线：在VSTS里设置流水线，添加打包任务（比如用tfx extension create命令打包成.vsix），再配置发布到Azure DevOps市场的任务，实现后续更新的自动化。
• 校验构建环境：确保流水线的构建环境（比如Node.js版本、依赖包版本）和本地开发环境一致，避免出现构建失败或功能不一致的问题。

关键注意事项 #

• 迁移前务必备份本地扩展的所有配置、源码和关联数据，防止意外丢失。
• 测试环节不能省：一定要在VSTS的测试项目里完整跑一遍扩展的所有功能，确认和本地TFS上的表现完全一致。
• 私有API适配：如果扩展用到了本地TFS的私有API，需要替换成VSTS支持的公开API，因为两者的API体系存在部分差异。

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