我们已将Team Foundation Server 2008部署为源控制管理系统。负责多种产品的团队要求将所有产品放在一个TFS项目下。他们的原因是因为这些产品都属于类似的领域。
以下是我的理由：
这只是一个整体糟糕的想法，但我想反对它的一些具体原因。如果我完全偏离基础，这是一个很好的方法，我也想听听。
有哪些优点/缺点？
答案 0 :(得分：4)
我有经验在TFS2008和TFS2010中的一个TFS团队项目下存储多个Visual Studio解决方案（单独的产品）。这是我的看法。
在两个版本中，我们都为Product创建了一个文件夹，然后为分支创建了一个文件夹（Main等）。这样可以很容易地看到我们正在处理的产品，并且我们可以看到产品的历史记录。其他产品。持续集成适用于多个构建定义，每个产品一个。我们只为整个TFS团队项目创建一个工作空间映射。
TFS2008的不足之处在于，管理每个产品的工作项可能很困难。在TFS2008中，工作项适用于整个团队项目，并且要弄清楚哪个工作项属于哪个产品并不容易。
在TFS2010中，工作项有“区域和迭代”部分。我们使用Area来定义产品。因此，每个工作项都会获得与产品名称匹配的区域。这对我们来说非常有效。
如果您在TFS2008中没有大量使用工作项目，我认为您不应该避免将多个产品放在一个TFS团队项目中，原因不在于您上面列出的原因。
使用一个团队项目确实有一些优势： 1.有一个团队项目需要管理，只有一个Share Point站点。 2.您可以轻松地在整个团队项目中查看历史记录。
答案 1 :(得分：2)
我的想法：
如果项目之间共享了程序集，那么将它们组合在一起是有意义的，否则你将遇到许多人在这里讨论过的关于如何处理共享程序集的相同问题。
您不应该遇到工作区映射的任何问题。在我们的组织中，我们只需将$ /映射到一个文件夹并从那里开始。否则，您可以非常轻松地将各个源控制文件夹映射到磁盘上的不同区域。我唯一的建议是将该映射放在批处理文件中，以便新成员可以运行批处理并保持一致。
通过将这些所有内容整合在一起，您可能会失败的唯一一件事就是快速简便的报告。如果所有内容都在自己的团队项目中，则内置报告可以“开箱即用”。如果你把事情放在一起，你需要设置额外的区域和迭代，以便进行报告和跟踪。
在我们的组织中，我们有15个独立的团队项目，但每个项目中都有不止一个“产品”。我们已经用这种方式运行了两年，除了报告之外，它确实没有任何问题。
答案 2 :(得分：0)
如果您不为其使用单独的模板，则将单个团队项目用于多个软件是完全可以接受的解决方案。 Martin Hinshelwood有一篇关于这个主题的详细博客文章。