最佳方法：重组现有的Team Foundation Server（TFS）解决方案

在我的部门中，我们正在为某些统一通信服务器开发几个较小的插件。对于版本控制和分布式开发，我们使用Team Foundation Server 2012。

但是：对于我们所有的应用程序和库，只有一个大型TFS解决方案：

• 主要解决方案
  • 应用领域
    
    • 应用程式1
    • 应用程式2
    • 应用程式3
  • 外在
  • 图书馆
    
    • 库1
    • 库2
  • 工具类

“应用程序”路径包含所有主要应用程序。它们并不相互依赖，但是取决于库和外部项目。

“外部”路径包含一些在我们的应用程序和库中引用的外部DLL。

库路径包含常用的库（UI模板，Helper类等）。它们彼此不依赖，并且在“库”和“工具”项目中被引用。

工具路径包含一些帮助程序，例如设置帮助程序，更新Web服务等。

现在，有一些要点为什么我想更改这种结构：

• 我们不能使用服务器版本。
• 用这样的解决方案结构来管理带有冲刺，障碍等的TFS Scrum管理是不舒服的。
• 每个开发人员始终可以访问解决方案中的所有项目。
• 如果在Visual Studio中意外击中[F6]，则完整的构建会持续太长时间。

您将在此解决方案中进行哪些更改？您如何将这些项目分解为较小的解决方案，应如何构建这些解决方案。

我的第一种方法是为每个应用程序，库和工具创建一个TFS项目。但是，如何确保例如App 2始终包含Lib 1的最新版本？我需要监视库1的更改并在库更改后立即手动更新App 2吗？还是可以以某种方式强制Visual Studio始终以某种方式使用外部项目的最新版本？

编辑：在TFS上，只有一个TFS团队项目集合，其中包含一个TFS团队项目。团队项目包含一个大型的Visual Studio解决方案，其中包含几个包含（请参见上面的结构）的文件夹，每个文件夹都包含多个VS项目。

我的问题是，现在您将如何重组：

1. TFS团队项目
2. VS项目

坚持一个TFS团队项目，尝试进行多个升级会变得很痛苦，并且在跨团队项目工作项方面存在一些局限性。相反，您应该大量使用Areas和Iterations。

将VS解决方案分为多个解决方案，每个主要应用程序一个。这将大大加快本地构建以及构建服务器的速度。

TFS2012有一个称为团队的新概念，为每个应用程序创建一个团队，并为每个应用程序设置默认的迭代和积压。这样，您可以管理每个的积压，或查看根团队以查看汇总的积压。然后，您可以根据需要在应用程序级别或整体上管理sprint。

为所有尚没有第三方引用的库创建NuGet软件包。将它们存储在专用存储库（Windows共享文件夹）中，并通过右键单击每个解决方案并启用它来启用NuGet的软件包还原功能（还允许软件包还原以vs设置下载软件包）。

如果您有任何共享的内部库，则还要为其创建NuGet软件包，并创建一个仅包含该库的vs解决方案。添加一个post build命令来创建nuget包，或者扩展您的tfs build模板来完成（有很多模板已经在执行此操作）。