原文地址1：http://hi.baidu.com/csuhkx/blog/item/675d18d181f5c4329a5027c4.html
原文地址2：http://hi.baidu.com/csuhkx/blog/item/943ce71797e51a03c83d6dc4.html
在本文的两个部分中，我将介绍Team Foundation Server的一些核心特征，重点介绍在本产品的日常应用中是如何将这些特性结合在一起使用的。
作为一名软件开发人员，在我的职业生涯中，我经常会用到支持软件开发过程的大量开发工具，如版本控制工具、漏洞跟踪包、生成脚本语言、单元测试框架 和需求分析工具等等。在.NET平台上，大量的支持工具能够很好地独立工作，但是，为了使得各种工具之间都够互相协作，还是经常需要一些手动工作。
随着Visual Studio产品线中Team Foundation Server组件的发布，微软使得开发团队在僵化的软件工程实践应用中取得了巨大进步。这并不是因为该产品包含的各种新增特性一定是最好的，关键因素是它 的集成性。
Team Foundation Server起步
Team Foundation Server(TFS)是这样一种服务器产品，它需要部署到软件开发环境中，这样开发人员就可以使用它提供的各种服务。因为TFS是设计用于大规模团队， 因而有两种拓扑结构供选择：双服务器和单服务器。
在单服务器部署中，TFS被安装在Windous 2003 server上，且该机器上已安装了SQL Server 2005数据库服务器、Web服务器IIS以及windows SharePoint Services。这种类型的安装可以满足大量用户需求，并且适用于大部分条件。
双服务器部署将SQL Server 2005 的数据库引擎和分析服务组件分开安装在不同的机器上，这样就可以实现可扩展性（通过增大用于大量用户注册操作的空间以及将处理负载的不同数据仓库安装在不 同的机器上实现，这种机器最大可达64位。）
安装了TFS服务器后，客户端可以通过安装Team Explorer来访问服务器。Team Explorer是一组组件，它包括简单版本的Visual Studio 2005（如果是在已经安装了Visual Studio 2005的机器上就仅仅是再添加更多功能）和大量用于微软的Excel和Project的插件，利用Excel和project可以访问存储在Team Foundation Server数据库中的数据。
Team Explorer可用于访问Team Foundation Server的以下特性：
- 过程引导
- 工作项跟踪
- 版本控制
- 自动生成
- 报告
创建一个团队项目
在开发团队可以使用Team Foundation Server之前，必须先创建一个团队项目，团队项目代表了一个所有团队活动都在这里发生的管理单元。为了创建一个团队项目，Team Foundation Server管理员需要打开Visual Studio 2005和 Team Explorer工具窗口（从视图菜单）。当打开Team Explorer 窗口后，就可以建立一个到服务器的连接。
右键单击树状视图中的服务器节点，TFS管理员就可以选择“新建团队项目”。事实上，这个选项通常是隐藏的，可见需要新建一个团队项目的情况是很少 的。绝大部分情况下，一个软件开发团队在一个大型软件的生命周期中仅有一个团队项目。
创建团队项目时，开发小组需要做的第一件事情是决定使用那个开发模型。
选择开发模型
Team Foundation Server允许开发小组选择他们想要使用的任何特定软件开发方法。下面的列表中提供了两种开发模型：
- 敏捷模型驱动软件开发
- 能力成熟度集成模型软件开发
每个开发模型都有一组特有的定制特性，包括定义工作项（要做的事情、要确定的事情、需求等等），过程管理和报告。下表显示了两个默认的开发模型中不 同工作项的分解：
| 敏捷模型驱动软件开发 | 能力成熟度集成模型软件开发
|
| 漏洞 服务要求的质量 风险 场景 任务 | 漏洞 改变请求 问题 需求 回顾 风险 任务 |
在这种情况下即使工作项的数目和名称存在差异，也应该指明使用这两种开发模型通用方法，而不是开发小组来推测他们该如何使用这些工作项类型，开发模 型可以包含一些可选的过程管理页面。
如果对话框中的模型不适合你的具体要求，可以订制它们以满足你的要求。事实上，已经有大量可以获得的第三方开发模型，如Scrum and process MeNtOR。
访问工作项存储器
创建了团队项目后，开发小组需要做的第一件事是分解已经创建的初始工作项集。这些工作项帮助开发人员完成一系列可以使得软件项目成功开始的活动，并 且依据不同的开发模型选择不同的工作项。通过展开团队项目节点，就可以看到工作项文件夹，继续展开然后打开查询文件夹可看到全部或部分工作项。
书写定制得工作项查询
最后需要书写一个新的工作项查询列表。新定义的查询可以放在“团队查询”和“我的查询”这两个文件夹的任何一个。团队查询是一个可被项目小组中的所 有开发人员访问的全局可访问容器，我的查询是一个由每个程序开发员所有的私有查询集。
我经常使用的一个有用的查询是Recycle Bin query，这个查询可用于打开最近关闭又需要重新打开的工作项（偶然关闭工作项的情况时有发生）。第一步是从工作项节点的背景菜单中选择“添加查询”。
在查询编辑器打开后，简单的用户接口就可以基于某些简单的表达式从工作项列表中过滤出需要的项目。在上面的情况中，查询设置为返回当前状态为关闭的 团队项目中的所有工作项。
应用Team Foundation Server的版本控制
访问了工作项，就可以应用Team Foundation Server中的版本控制。像TFS中的其它特征一样，版本控制功能位于SQL Server 2005之上，用于提供良好的性能和可扩展性（实际上，宿主在TFS中的版本控制存储器的大小估计有千兆字节。开发小组可能遇到的第一个与版本控制相关的 工作项是迁移已经存在的源代码，这个工作项提供了在迁移源代码是需要做什么的详细视图。
配置一个工作区
在程序员将文件添加到版本控制存储器之前，需要将版本控制存储器的逻辑结构映射到本地机器上的文件系统。Team Foundation Server 引入了工作区的概念。工作区是物理位置和文件系统间的一组映射，一个文件系统与一个特殊用户和计算机组合相匹配。在文件上进行工作的程序员，他们是逻辑的 进出工作区。为了建立一个工作区，程序员需要双击Team Explorer中的源码控制图标，到工作区下拉菜单。
我发现将整个源代码树的根映射到本地驱动器上的一个具体位置并将其作为唯一映射是最简单的方法。我自己的方法是在我的数据驱动器的根目录上创建一个 “沙盒”目录，在它的下级有一个子目录，将其命名为我连接到的TFS服务器的名字。（我连接到了多个TFS服务器，因此一定要注意避免混淆）。
建立了映射之后，浏览源代码控制浏览器将会列出源代码树上逻辑位置的本地路径。至此你就可以添加源代码到这个容器中。
程序员面对的一个局限是他们不能将文件添加到版本控制存储器的根中（$/），且所有以及文件夹都直接和某个特定团队项目相关。这里面的逻辑是，一个 Team Foundation Server可用于大量项目，每个项目应该在它们自己的区域内工作。
添加源代码到Team Foundation Server
在Team Foundation Server中安排源代码有无数的方式，你为什么选用这种而不用另一种，详细的原因说明超出本文的范围。下面选择的方式仅是一个用于演示例子。特别的地方 是，我选择添加了三个字文件夹：Trunk, Branches 和Releases，如下图。
文件夹添加到版本控制系统后，其他的程序员并不会立即看到，他们必须像文件一样进行注册。在本例中，在注册前我将添加一组解决方案和项目文件到这个 容器中，然后一起注册。
除了增强了性能和扩展性外，TFS将其版本控制系统安装在SQL Server 2005上，这意味着，进行原子提交和注册的方法是可能的。也就是说，要么全部注册成功，要么全部失败。注册可以在源代码控制浏览器或解决方案浏览器上执 行（或者在强制改变工具窗口中进行）
版本控制系统和工作项存储器在注册时集成在一起。当注册时，可以将其与一个或多个工作项关联。例如，因为这是刚引入源代码，所以我可以浏览注册对话 框中的工作项视图，选择工作项3387和它关联。注意当关联工作项时无论默认的选择如何都要将注册行为设定为 “解决”，这样做的目的是防止任务关闭工作项，因此较早建立十分有用的Recycle Bin 查询。
建立一个注册，就叫做一个改变集，一个源代码容器不过是一系列不断彼此堆积起来的改变集。因为在数据库中改变集是一个可以区分的实体，因此可以将数 据和它关联在一起，所以上面建立的改变集和工作项3387的关系可以在改变集中浏览或者在工作项中浏览。下面的屏幕截图显示了连到工作项的改变集。
新概念：搁置集
和Team Foundation Server中的版本控制相关的一个新概念是搁置集。搁置集的思想是程序员在过周末休息时，可以将在工作日做的改变放在某个安全的地方。建立一个搁置集相 当简单，首先，程序员在解决方案浏览器中的背景菜单中选择“搁置必要的改变”，然后出现下面的对话框。
程序员可以给搁置集一个名字，以便以后可以查找和恢复它，和注册对话框一样，搁置集也可以添加评论和关联工作项。搁置集仅包含修改过的文件，因为改 变集版本是从版本控制存储器引出的，所以创建他们的相当简单。
为了恢复搁置集，可以选择背景菜单中的“解冻必要改变”选项，程序员可以查找由他们或其他程序员建立的搁置集。
事实上搁置集可以共享，这意味着它们可以很好的执行代码预览，增强单注册点策略，这对一个特别项目在封装时可能很十分有用。
在本文的下一部分，我将详细介绍搁置集，TFS中完善的分支支持，TFS是如何支持自动生成的并介绍一下报告功能提供的功能。
在本文的第一部分我们介绍了TFS的工作项跟踪特性，并简单地介绍了版本控制特性。在第二部分中，我将继续给大家介绍版 本控制的特性，然后介绍TFS中的Team Build和报告工具。
建立分支与合并代码
对于在开发中支持一个或多个代码版本的开发小组来说，开发和使用一个他们的软件新版本是十分重要的，同时具备维护两个不同版本的代码库的能力也非常 重要。分解与合并工具使的这一切成为可能，在大多数现代版本控制系统中都可以获得这些工具。Team Foundation 的版本控制也不例外。
TFS的分解支持能力，至少从表面上看起来与Subversion或VSS没有什么不同。利用VSS我们可以将一颗树的部分拷贝放置到另一个路径。 例如你可以为$/DemoProject/Trunk 建立分支$/DemoProject/Branches/FeatureTeam1，从而一个特性小组可以在建立的分支上编写代码而不必扰乱主干部分。
建立一个分支十分简单：首先，你需要从源代码控制窗口中选择你想要建立分支的文件夹，然后从上下文菜单中选择“分支”。将会弹出一个对话框，在里面 你可以浏览或者输入你打算存放拷贝文件的目的地。
单击确定就在你的本地工作站上面建立了一个分支，然后你必须浏览该分支，分别检查里面的各类代码。在源代码控制窗口中，一个挂起的分支操作用两个分 级箭头标出。
因为分支存在于一颗树中逻辑上独立的部分，这就允许开发人员可以直接在分支中编辑源文件，然后提交给影响每个分支的版本控制存储器。虽然这看起来有 点不固定，但是当你有几个不同版本的代码库时或者需要将一个漏洞补丁应用于每个文件时，这将会变得非常有用。
执行合并
有人说建立分支很简单，但是合并起来确实很受伤。在我看来这话确有道理，尤其是那些对于离开主干很久的分支。下面的做法对开发小组来说通常是个不错 的办法，按照一个常规的原理定期合并代码，只要确保不出现令人厌恶的千奇百怪就行。
从技术的角度看，执行代码合并没什么困难的。第一步你需要在源文件控制窗口中选择你想要合并的分支，然后从上下文菜单中选择合并，这将会弹出一个向 导对话框，帮助你晚场合并过程。
如果你毫无根据的进行合并，向导将会阻止你的操作。比如，你将在一个源文件树中没有直接祖先关系的两个位置的代码进行合并，这时向导就会阻止合并。 这限制大多数工具存在，因为这将导致复杂性和迷惑性。然而，如果你确实想要执行无根据的合并，请考虑试用一下Team Foundation Server的动力玩具。
合并操作过程中几乎没有不发生冲突的，因此当TFS检测到冲突时，会弹出一个对话框，需要开发人员选择进行哪个改变。
理想情况下，你可以选择自动合并全部，然后去喝杯咖啡，但是依我的经验看来，这样做并不怎么聪明，自动合并有时会出现莫名其妙的选项。所以我更喜欢 手工合并每个文件。
对于大量复杂的合并操作，我建议将小组核心开发人员带到一个配有投影仪和膝上电脑的房间，让他们一起完成合并工作，因为这个过程需要他们的集体智 慧。
自动生成
在执行生成时，我始终认为要坚持这样一个基本依据，那就是要保护代码库的安全。在Team Foundation Server中支持这一特性的是Team Build系统，该系统扩展了MSBuild的功能，支持将生成任务分配到一个或多个生成服务器上完成。
TFS中的每个生成被注册成Team Build类型，该类型定义了生成必须执行的各种参数。其中必须指明的参数包括生成类型名，在版本控制中的那个解决方案将被生成，什么样的配置（例如 X64 Release），使用哪台生成服务器以及生成结果存储在何处。也可以将自动测试包含到生成中，测试包括代码覆盖和静态代码分析。
一旦创建了Team Build 类型，生成脚本就可以用来订制执行一些向导中不支持的额外操作。Team Build类型和Team Project始终存放在版本控制存储器中明显的地方，例如，如果我的生成类型名 为：“TrunkHelloWorldSolutionContinuous”，那么DemoProject的源码控制区应该 为：“$/DemoProject/TeamBuildTypes/TrunkHelloWorldSolutionContinuous”。
剔除和管理生成
Team Explorer通过分析版本控制存储器组装Team Project树上的Team Builds节点，决定定义了那些Team Build类型。呈交的每个节点都可以用来剔除一个生成。
Team Foundation Server利用指定的生成服务器管理通讯，并提供一个生成进度摘要。这对于很长的生成来说非常有用，因为这样可以看到生成进度情况。生成完成后，生成摘 要随即转换成一份详细的生成报告，该报告将会显示生成过程中发生些什么以及用到了那些改变集和工作项。
双击Team Explorer中的Team Build 类型，所有以前的生成将会被重新找回，并且每个都会有一个质量状态指示器。通过这种方式，我们可以使用Team Build 系统来管理生成过程，尽管很多人还没有认识到这是Team Build 系统有意为之。
我们可以利用一个特别的生成返回工具从报告某个问题的过程中返回。通过代码和所有其它方式返回到需求。从工具集成的角度来看这是一个巨大的进步，也 是高集成度对开发小组有所帮助的生动例子。
报告
通过在Team Foundation Server中集成工作项跟踪，版本控制和自动生成系统，微软为我们提供了一个非常有价值的相关信息存储器，以后逐渐变成报告生成的重要来源。在Team Foundation Server应用之前，大量开发小组只能通过用掐算手指头的方法来估计和报告工作进展。现在，利用Team Foundation Server我们就可以准确地看到我们的工作进展。
使用Team Foundation Server进行开发，存储在潜在的关联数据库中的信息会被输入到一个分析器中，然后利用该分析器来生成各种各样的报告，报告可以使用SQL Server报告服务工具查看。
每个过程模板都有一个不同的报告集，我们可用这些报告找回和某个特定的软件开发过程相关的数据。如上图所示，就是利用MSF为快速软件开发模板生成 的报告。
这仅仅是报告服务和TFS分析器强大功能的冰山一角，它们还可以订制用来满足你的特殊需要，订制方法也很简单，只需要为你的服务器部署一个新的报告 即可。
小结
在本文的两个部分中，我们介绍了Team Foundation Server的几个关键特性领域，包括过程管理，工作项跟踪，版本控制，自动生成和报告。因为TFS是一个庞大的产品，因此我们不可能仅在一篇文章中对每 个特性都给出详细的介绍，更不用说伴随各个版本Visual Studio 2005的客户端特性。希望本文能够抛砖引玉，使你对该产品的功能以及对开发小组带来的有益之处有所了解。
在你决定使用微软的产品，定购Team Foundation Server之前，你需要看看这个工具是否适合你。为此，我给大家提供下面关于该产品的优缺点列表供参考。
| 优点 | 缺点 |
| 可靠的版本控制存储器可根据需要调整容量 | 不能像VSS一样随意拿起移动，并且其中的一些混合可能开始就让人迷惑。 |
| 收集公有模式，并将它们以一种简单易懂的格式呈现出来。 | 收集公有模式，并将它们以一种简单易懂的格式呈现给人们，但是你可能不像去理解这些东西。 |
| 将项目经理和小组负责人从耗时的工作中解放出来 | 虽然服务器本身相对便宜，但是客户端访问注册和该产品的团队版却十分昂贵。 |
| 达到的集成度通过将其它的各类产品结合在一起的方法很难达到。例如，代码漏洞跟踪，需求分析工具 | 一旦安装，就需要小组中的一名具备构建技术的人员进行管理。 |
| 工作项跟踪可以使开发人员对下一步的工作有一个计划。 |
|
总的来说，我感觉TFS对于我所接触到的所有开发小组都发挥了积极的作用。最后，我想给大家提供一些资源，这些资源曾使我的TFS体验更加有趣。
| 资源 |
|
| TeamPlain Web 访问 | TeamPlain是一个第三方产品，它可以为Team Foundation Server上的基于Web的接口提供一个漂亮的界面。该产品对于那些不想学习使用Visual Studio 2005工具的商业分析家，项目赞助商和辅助人员等提供了很好的TFS体验。 |
| TFS集成器 | TfS集成器是由Readify(我在该公司工作)开发工具，该工具为TFS提供了持续的集成性和依赖复制支持。这极大地 方便了复杂生成过程的管理，由该领域的资深人员开发。 http://notgartner.wordpress.com/2006/09/18/getting-started-with-tfs-integrator/ |
| TFS部署工具 | TFS部署工具是由Readify开发的另一个工具，该工具可以让发行经理利用Team Build中的性能指示器轻松地将软件部署到复杂的环境中（比如说多服务器环境）。 http://notgartner.wordpress.com/2006/12/16/getting-started-with-tfs-deployer/ |
| Team Foundation 动力玩具 | 一个封装到包中的实用工具集，使用它可以让你做一些并不暴露在TFS中的事情。 |