tfs - 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 Deployer