在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

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的假设,因为我还在学习)您可以从同一个Collection中跨项目进行分支,但不能跨集合进行分支.
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美元......