Question

我将管理TFS 2010到2012的迁移/更新。我借此机会重新组织我们的存储库结构。

我们是一个非常庞大的组织，有许多部门。我们为每个部门提供了许多不相关的软件应用程序。

当前结构是一个集合，每个部门都有自己的团队项目。每个应用程序都保存在属于的Team Project下的文件夹中。

/DefaultCollection
 /MediaTeamProject
   /MediaWebsite
   /MediaMobileApp
   /MediaCRM
 /Transport
   /TransportSchedulingApp
   /TransportGPSApp
   /TransportWebsite

到目前为止，TFS已被用于源代码控制，但我想开始利用其ALM功能。我的想法是在这次迁移过程中，我会为每个部门创建一个集合，每个解决方案都有自己的团队项目：

/MediaCollection
 /MediaWebsiteTeamProject
 /MediaMoobileAppTeamProject
 /MediaCRMTeamProject
/TransportCollection
 /TransportSchedulingAppTeamProject
 /TransportGPSAppTeamProject
 /TransportWebsiteTeamProject

这些软件应用程序彼此无关。我的想法是，一旦我隔离了每个软件应用程序，我就可以在我们的开发团队中利用Team Web Access。

这个结构是否正确，还是我错过了船？我问，如前一个问题，有人提到我们现有的结构很好，我应该使用“团队”（Migrate TFS folder into Team Project）

Microsoft在其文档中指出：“从逻辑上（或概念上），团队项目是一个单一的基础架构，包含软件应用程序开发生命周期中使用的所有独立工具和元素。”参考：http://msdn.microsoft.com/en-us/library/ms181234(v=vs.90).aspx

它似乎描述了软件应用程序和团队项目之间的1：1关系。

鉴于每个软件应用程序与任何其他应用程序无关，并且我们想要使用ALM，我应该将每个应用程序隔离到自己的团队项目中，还是应该做其他事情？

Answer 1

如果项目不相关，这是一个很好的策略。无论你选择什么，最重要的挑战是理解其含义，主要是：

使用团队项目集合，您将获得：

物理和逻辑隔离：每个集合存储在不同的数据库中。这允许维护每个集合而不影响其他集合。物理隔离最适用于咨询/外包开发方案。
更好的可扩展性。
每个集合都需要自己的服务器和硬件（构建控制器，测试控制器，SharePoint门户等）。
不在集合之间共享代码和工作项。

使用单个团队项目集合：

更简单的数据模型，意味着更简单的可维护性，更少的存储要求和更轻松的备份。升级也会更容易。
没有物理隔离意味着某些用户可能会看到其他项目数据。但是，由于管理团队只遵循一套规则，因此提供支持应该更容易。
减少系统和硬件要求。
允许共享代码和工作项。

最重要的是，为了增强安全性和隔离方案，请选择多个“团队项目集合”选项。否则坚持单一集合的简单性。

Answer 2

您指出项目是不相关的，但如果处理这些项目的开发人员在多个项目上工作，则每个应用程序创建一个团队项目的开销可能更难以管理，因为每个项目都有自己的权限集并且必须作为完全独立的实体进行管理。因此，在同一个TFF项目中尽可能分组解决方案可能有所帮助。

创建多个集合将有助于恢复，因为假设使用合理的做法来分发和备份数据库，可以降低灾难性故障的风险。

组织TFS存储库

2 个答案:

使用团队项目集合，您将获得：

使用单个团队项目集合：