TFS 2010 中的项目结构 [英] Project structure in TFS 2010

查看:36
本文介绍了TFS 2010 中的项目结构的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

We have just gotten TFS 2010 up and running. We will be migrating our source into TFS but I have a question on how to organize the code.

TFS 2010 有一个新的项目集合概念,所以我决定我们组织内的不同组将拥有自己的组.我的团队开发了许多不同的 Web 应用程序,我们有几个共享组件.我们还使用了一些第三方组件(例如 Telerik).

TFS 2010 has a new concept of project collections so I have decided that different groups within our organization will get their own group. My team develops many different web applications and we have several shared components. We also use a few third party components (such as telerik).

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

Clearly each web application is it's own project but where do I put the shared components? Should each component be in it's own project with separate builds and work items?

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

Is there a best practice or recommended way to do this specific to TFS 2010?

推荐答案

对此的最佳做法是在 Main/Trunk 文件夹下拥有构建解决方案所需的一切.我们使用以下格式:

The best practice for this is to have everything that you need to build a solution under your Main/Trunk folder. We use the following format:

 "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)

这会将您的所有分支保持在同一级别,因此您无需怀疑哪个是分支,哪个是文件夹.

This keeps all of your branches at the same level so you do not have any doubt as to which is a branch and which is a folder.

这是您的团队项目结构,但是每个分支下的实际文件夹结构呢:

That's your Team Project structure, but what about the actual folder structure under each of the branches:

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 的新版本并不意味着另一个团队选择不这样做,因为这是几周的工作.

The idea is that it is the team's choice whether to use a new version of an external product or reference library. Just because one team can upgrade to a new version of NUnit does not mean that another team chooses not to as it is weeks of work.

无论如何都有一个中央工具"项目,您总是使用最新版本进行更新,您的团队从那里提取,但没有外部依赖项.它使自动构建成为一场噩梦,并使您的开发人员升级,即使现在不是一个好时机.最重要的是,确保将任何外部依赖项视为工具,即使它来自另一个内部团队.

By all means have a central "Tools" project that you always update with the latest and your team pulls from there, but do not have external dependencies. It makes it a nightmare to do automated builds and makes your developers upgrade even if it is not a good time. On top of that make sure you treat any external dependency as a Tool even if it is from another internal team.

参考资料: TFS 部署器

这篇关于TFS 2010 中的项目结构的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆