关于TFS 2017.3.1本地部署环境合并集合的技术问询

针对你要把小型集合合并到大型集合的需求，结合我处理过的类似场景，给你梳理可行的方案、工具注意事项以及潜在风险：

可用工具与操作步骤 #

微软官方没有直接的「集合合并」工具，但可以通过跨集合内容迁移的方式实现目标，覆盖Git、工作项、构建发布等全功能。具体步骤和工具如下：

1. 前置准备 #

• 全量备份两个集合：使用TFS管理控制台的「备份集合」功能，或者命令行工具 TfsBackup.exe 执行备份，避免迁移过程中数据丢失。
• 排查命名冲突：确认大型集合中没有与小型集合重复的项目名称、Git仓库名、工作项类型名，避免迁移后出现冲突。

2. 各组件迁移方法 #

• Git仓库：
  采用镜像克隆+推送的方式完整保留历史：

  # 克隆小型集合的Git仓库镜像
  git clone --mirror <小型集合Git仓库URL>
  cd <仓库目录>
  # 推送到大型集合的新Git仓库（需提前在大集合创建空仓库）
  git push --mirror <大型集合Git仓库URL>
  

  也可以直接在大型集合的项目中使用「导入仓库」功能，输入小型集合仓库的URL完成迁移。

• 工作项：

  • 先迁移工作项类型定义：使用 witadmin exportwitd 导出小型集合的工作项类型，再用 witadmin importwitd 导入到大型集合的目标项目中。
  • 批量迁移工作项：可以用Excel批量导出小型集合的工作项（包含历史记录），再导入到大型集合；或者编写PowerShell脚本调用TFS REST API，实现工作项的批量创建并保留历史、链接关系。

• 构建与发布定义：

  • 构建定义：使用 tf build export 命令导出小型集合的构建定义JSON文件，然后在大型集合中用 tf build import 导入，同时提前配置好对应的代理池、服务连接、变量组。
  • 发布定义：通过TFS REST API导出发布定义的JSON，再导入到大型集合，注意检查环境配置、部署组等依赖是否在大集合中存在。

• TFVC源代码管理：
  使用 tf vc migrate 命令将小型集合的TFVC仓库迁移到大型集合，或者先将小型集合的TFVC仓库映射到本地，再在大型集合的TFVC仓库中创建对应路径并提交，尽量保留历史版本。

第三方工具对微软MSDN支持的影响 #

微软的官方政策是：如果第三方工具仅做数据层面的读写（读取源集合数据，写入目标集合，不修改TFS底层数据库结构或核心服务），不会影响后续的MSDN技术支持。但如果第三方工具修改了TFS的数据库 schema 或者核心组件，微软可能会拒绝提供支持。

另外，你提到的那款已停止支持的集成工具，不建议使用——没有维护的工具可能存在兼容性问题，甚至导致数据损坏，反而增加后续风险。如果要使用第三方工具，优先选择仍在维护、且明确声明不修改TFS底层结构的工具，迁移前最好同步操作记录给微软支持确认。

迁移后潜在的后续问题 #

合并操作后可能会遇到以下问题，提前做好预防：

• 命名冲突：如果迁移前未排查完全，可能出现同名项目、仓库导致的覆盖或访问异常，迁移前务必做全量的命名检查。
• 历史记录不完整：部分工作项迁移方法可能无法完全保留所有历史操作记录（比如评论、附件），建议先做小范围测试，确认历史记录完整性。
• 依赖断裂：构建/发布定义中的服务连接、变量组、代理池在大型集合中可能未配置，迁移后需要逐一验证并补全依赖。
• 权限混乱：小型集合的权限组与大型集合可能不一致，迁移后需要重新配置项目权限，确保用户能正常访问对应资源。
• 性能下降：合并后大型集合的数据量显著增加，需要检查TFS服务器（尤其是数据库服务器）的CPU、内存、存储是否能支撑，必要时升级硬件。

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