19

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

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

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

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

4

4 回答 4

13

最佳实践是在 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 部署器

于 2010-05-06T15:53:29.997 回答
5

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

对我们来说，我们有一套 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 美元价值...

于 2010-04-23T15:51:57.330 回答
4

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

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

于 2011-04-19T15:24:04.063 回答
2

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

于 2010-08-01T23:08:45.493 回答