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

Answer 2

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

对于我们来说，我们有一套网络应用程序，它们都有许多共享组件。因此，虽然这是大约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相关的好处。

然而，在你的场景中，如果我正确地在线之间阅读，我会建议一些不同的东西。我的假设：

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

所以有了这些假设，我会选择这样的东西：

"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时，我们将程序集所在的文件夹分支到目标项目的“ThirdParty”文件夹中。

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

Answer 4

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

在TFS 2010中组织源代码

4 个答案: