TFS 2010 中的项目结构

Question

我们刚刚启动并运行了 TFS 2010。 我们将把我们的源代码迁移到 TFS，但我有一个关于如何组织代码的问题。

TFS 2010 有一个新的项目集合概念，所以我决定我们组织内的不同组将拥有自己的组。 我的团队开发了许多不同的 Web 应用程序，我们有几个共享组件。 我们还使用了一些第三方组件（例如 Telerik）。

显然，每个 Web 应用程序都是自己的项目，但我应该将共享组件放在哪里？ 每个组件都应该在它自己的项目中，并具有单独的构建和工作项吗？

是否有针对 TFS 2010 执行此操作的最佳实践或推荐方法？

Answer 1

最佳做法是在 Main/Trunk 文件夹下拥有构建解决方案所需的一切。 我们使用以下格式：

 "Project 1"
   "DEV" (Folder)
      "Feature 1" (Branch)
      "Main" (Root branch)
   "Release" (Folder)
      "Release 1" (Branch)
   "RTM" (Folder)
      "Release 1.0" (Branch)
      "Release 1.1" (Branch)

这使您的所有分支保持在同一级别，因此您不会怀疑哪个是分支，哪个是文件夹。

这是您的团队项目结构，但是每个分支下的实际文件夹结构呢：

Main (Root branch)
  "Builds" (Folder that contains all of the MSBuild and Workflows for building)
  "Documents" (Folder that contains version specific documents)
  "Deployment" (Folder that contains config required for deployment | We use TFS Deployer from Codeplex)
  "Setup" (Folder contains all of the setup resources)
  "[Company].[Namespace].*" (Folders that contains a project)
  "Tools" ( Folder for all your nuts and bolts)
     "Toolname" (Folder for a specific tool or reference library)

这个想法是由团队选择是否使用外部产品或参考库的新版本。 仅仅因为一个团队可以升级到 NUnit 的新版本并不意味着另一个团队选择不这样做，因为这是几周的工作。

无论如何，拥有一个中央“工具”项目，您始终使用最新版本进行更新，您的团队从那里提取，但没有外部依赖项。 它使自动构建成为一场噩梦，并使您的开发人员升级，即使现在不是一个好时机。 最重要的是，确保将任何外部依赖项视为工具，即使它来自另一个内部团队。

参考资料： TFS 部署器

Answer 2

我有两个答案：我们做什么以及我为您建议什么。

对我们来说，我们有一套 Web 应用程序，它们都有许多共享组件。 因此，尽管这是大约 50 个不同的程序集（VS 项目）和 5-10 个解决方案（取决于您如何看待它），但它们之间存在非常显着的重叠，这意味着我们希望使用 TFS per-dev 合并而不是而不是分支和合并那些重叠的资源。 因此，我们实际上将所有这些都保存在一个 TFS 项目中。 以下是我们的设置方式（已更改名称以对您有意义）：

"Official Projects" (Collection)
    "Production Applications" (Project)
    "Technology Proof of Concepts" (Project)
    "Reference Projects" (Project) - this is a simple solution/projects using our architecture to make our architecture easier to understand as people join our team. Other reference apps will go here in the future.
    "TFS Configuration" (Project)
"Playground" (Collection)
    "John Doe" (Project)
    "Jane Doe" (Project)
    "Security Team" (Project)
    "Production Test" (Project)

在我们的设置中，我们有一个用于存放官方公司代码的地方。 此外，我们还有一个区域供人们闲逛而不必担心搞砸任何事情，同时能够利用各种与 TFS 相关的好处。

但是，在您的情况下，如果我正确阅读了两行之间的内容，我会建议一些不同的内容。 我的假设：

1. 除了具有一些通用程序集（我认为日志记录、安全性和其他在公司范围内共享的实用程序程序集）之外，每个项目都是不相关的项目。
2. 共享/公共程序集不会定期更改，因此您可以使用 DLL 引用而不是项目引用，在这种情况下，您始终使用最新的最新/每日版本的代码。
3. （基于 TFS 的假设，因为我还在学习）您可以从同一个集合中跨项目分支，但不能跨集合分支。
4. 除了上述共享程序集之外，没有其他代码在团队之间共享。

因此，根据这些假设，我会采用以下方法：

"Common Resources" (Collection)
    "Source" (Project) - everything goes here such as logging assemblies, security assemblies, etc.
    "Version 1" (Project) - Branch as you "rev" your common assemblies so people have access to older versions.
    "Version 2" (Project)
    "Version 3" (Project"
    etc.
"Team 1" (Collection)
    "Project 1"
    "Project 2"
    "Project 3"
    "Project 4"
    "Project 5"
"Team 2" (Collection)
    "Project 1"
    "Project 2"
    "Project 3"
"Team 3" (Collection)
    "Project 1"
    "Project 2"
etc.

通过这种方式，您可以通过 DLL 引用来引用公共程序集。 作为特定项目的团队或开发人员，您可以决定何时开始使用较新版本的通用程序集。 为此，您只需在该版本的分支上获取最新信息，然后添加对它的引用。 如果我的假设 #3 是错误的，那么希望你能做得更好。 否则，每个项目都有自己的空间（可以包含不止一个 VS 解决方案/项目，这是一个好主意），并且您的团队拥有自己的集合以与其他团队保持距离。

只是我价值 0.02 美元...

Answer 3

我们对第三方组件采取了一种简单的方法，并为它们创建了一个单独的项目。 然后，当另一个项目需要引用程序集或 DLL 时，我们将程序集所在的文件夹分支到目标项目中的“第三方”文件夹中。

这也为我们提供了一种机制，可以使用基本文件夹的前向合并以渐进的方式推出对第三方程序集的升级。

Answer 4

使用工作区，它们不仅适用于团队集合，而且适用于大多数版本控制技术。