在TFS 2010中组织源代码

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

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

显然，每个Web应用程序都是自己的项目，但我在哪里放置共享组件？每个组件是否应该在自己的项目中使用独立的构建和工作项目？

是否有最佳做法或推荐的方法来做到这一点特定于TFS 2010？

2010-04-21 HitLikeAHammer

对此的最佳实践是拥有在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

来源

2010-05-06 15:53:29

您是否可以更新结构以指示.sln和.csproj文件的位置？我目前有一个场景，其中每个可部署项目（Windows服务或Web应用程序）都有解决方案，并且每个解决方案都可以依赖于解决方案中的项目（例如，一个解决方案中的接口项目由另一个解决方案中的另一个项目）。你的建议是否迎合了这个？我们目前在构建到已知位置时手动复制可分发程序集，并预先构建我们在依赖项中复制的其他项目并引用副本。 – jamiebarrow 2011-08-03 16:03:51

我有两个答案：我们做什么和我为你建议的。

对于我们来说，我们有一套Web应用程序，它们都拥有很多共享组件。因此，虽然这是大约50个不同的程序集（VS Projects）和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的假设，因为我仍然在学习）您可以跨同一集合中的各个项目进行分支，但是您无法跨集合进行分支。
除了上述共享程序集之外，其他代码不会在团队间共享。

因此，与这些假设，我会去像这样的东西：

"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-23 15:51:57 Jaxidian

你是对的，你不能跨集合分支 – 2010-05-06 15:55:12

我不喜欢你的最新版本分支上的最新评论，并添加一个引用。这会在您使用自动化buid时导致问题，并且无法解决。最好在yoru解决方案文件夹中添加一个Tools文件夹，并在那里共享资源。这可以防止在线后面引用问题，并且不需要分支公共资源。 – 2010-05-06 15:59:51

但是我喜欢你的球队收藏:)但是当球队1期望它的盘子太多并且想把项目2交给球队3时会发生什么？ – 2010-05-06 16:02:29

使用工作区，它们不是跨团队集合只有工作，但与大多数版本的技术工作。

来源

2010-08-01 23:08:45 Mike

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

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

来源

2011-04-19 15:24:04

在TFS 2010中组织源代码

回答

相关问题