VS2010 TFS
在本文的两个部分中，我将介绍Team Foundation Server的一些核心特征，重点介绍在本产品的日常应用中是怎样将这些特性结合在一起使用的。
作为一名软件开发者，在我的职业生涯中，我常常会用到支持软件开发过程的大量开发工具，如版本号控制工具、漏洞跟踪包、生成脚本语言、单元測试框架 和需求分析工具等等。在.NET平台上，大量的支持工具可以非常好地独立工作，可是，为了使得各种工具之间都够互相协作，还是常常须要一些手动工作。
随着Visual Studio产品线中Team Foundation Server组件的公布，微软使得开发团队在僵化的软件project实践应用中取得了巨大进步。这并非由于该产品包括的各种新增特性一定是最好的，关键因素是它 的集成性。
Team Foundation Server起步
Team Foundation Server(TFS)是这样一种server产品，它须要部署到软件开发环境中，这样开发者就能够使用它提供的各种服务。由于TFS是设计用于大规模团队， 因而有两种拓扑结构供选择：双server和单server。
在单server部署中，TFS被安装在Windous 2003 server上，且该机器上已安装了SQL Server 2005数据库server、WebserverIIS以及windows SharePoint Services。这样的类型的安装能够满足大量用户需求，而且适用于大部分条件。
双server部署将SQL Server 2005 的数据库引擎和分析服务组件分开安装在不同的机器上，这样就能够实现可扩展性（通过增大用于大量用户注冊操作的空间以及将处理负载的不同数据仓库安装在不 同的机器上实现，这样的机器最大可达64位。）
安装了TFSserver后，client能够通过安装Team Explorer来訪问server。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 窗体后，就能够建立一个到server的连接。
右键单击树状视图中的server节点，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中的源代码控制图标，到工作区下拉菜单。
我发现将整个源码树的根映射到本地驱动器上的一个详细位置并将其作为唯一映射是最简单的方法。我自己的方法是在我的数据驱动器的根文件夹上创建一个 “沙盒”文件夹，在它的下级有一个子文件夹，将其命名为我连接到的TFSserver的名字。（我连接到了多个TFSserver，因此一定要注意避免混淆）。
建立了映射之后，浏览源码控制浏览器将会列出源码树上逻辑位置的本地路径。至此你就能够加入�源码到这个容器中。
程序猿面对的一个局限是他们不能将文件加入�到版本号控制存储器的根中（$/），且全部以及目录都直接和某个特定团队项目相关。这里面的逻辑是，一个 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，从而一个特性小组能够在建立的分支上编写代码而不必扰乱主干部分。
建立一个分支十分简单：首先，你须要从源码控制窗体中选择你想要建立分支的目录，然后从上下文菜单中选择“分支”。将会弹出一个对话框，在里面 你能够浏览或者输入你打算存放复制文件的目的地。
单击确定就在你的本地工作站上面建立了一个分支，然后你必须浏览该分支，分别检查里面的各类代码。在源码控制窗体中，一个挂起的分支操作用两个分 级箭头标出。
由于分支存在于一颗树中逻辑上独立的部分，这就同意开发者能够直接在分支中编辑源文件，然后提交给影响每一个分支的版本号控制存储器。尽管这看起来有 点不固定，可是当你有几个不同版本号的代码库时或者须要将一个漏洞补丁应用于每一个文件时，这将会变得很实用。
运行合并
有人说建立分支非常easy，可是合并起来确实非常受伤。在我看来这话确有道理，尤其是那些对于离开主干非常久的分支。以下的做法对开发小组来说一般是个不错 的办法，依照一个常规的原理定期合并代码，仅仅要确保不出现令人厌恶的千奇百怪即可。
从技术的角度看，运行代码合并没什么困难的。第一步你须要在源文件控制窗体中选择你想要合并的分支，然后从上下文菜单中选择合并，这将会弹出一个向 导对话框，帮助你晚场合并过程。
假设你毫无依据的进行合并，向导将会阻止你的操作。比方，你将在一个源文件树中没有直接祖先关系的两个位置的代码进行合并，这时向导就会阻止合并。 这限制大多数工具存在，由于这将导致复杂性和迷惑性。然而，假设你确实想要运行无依据的合并，请考虑试用一下Team Foundation Server的动力玩具。
合并操作过程中差点儿没有不发生冲突的，因此当TFS检測到冲突时，会弹出一个对话框，须要开发者选择进行哪个改变。
理想情况下，你能够选择自己主动合并所有，然后去喝杯咖啡，可是依我的经验看来，这样做并不怎么聪明，自己主动合并有时会出现莫名其妙的选项。所以我更喜欢 手工合并每一个文件。
对于大量复杂的合并操作，我建议将小组核心开发者带到一个配有投影仪和膝上电脑的房间，让他们一起完毕合并工作，由于这个过程须要他们的集体智 慧。
自己主动生成
在运行生成时，我始终觉得要坚持这样一个基本根据，那就是要保护代码库的安全。在Team Foundation Server中支持这一特性的是Team Build系统，该系统扩展了MSBuild的功能，支持将生成任务分配到一个或多个生成server上完毕。
TFS中的每一个生成被注冊成Team Build类型，该类型定义了生成必须运行的各种參数。当中必须指明的參数包含生成类型名，在版本号控制中的那个解决方式将被生成，什么样的配置（比如 X64 Release），使用哪台生成server以及生成结果存储在何处。也能够将自己主动測试包含到生成中，測试包含代码覆盖和静态代码分析。
一旦创建了Team Build 类型，生成脚本就能够用来订制运行一些向导中不支持的额外操作。Team Build类型和Team Project始终存放在版本号控制存储器中明显的地方，比如，假设我的生成类型名 为：“TrunkHelloWorldSolutionContinuous”，那么DemoProject的源代码控制区应该 为：“$/DemoProject/TeamBuildTypes/TrunkHelloWorldSolutionContinuous”。
剔除和管理生成
Team Explorer通过分析版本号控制存储器组装Team Project树上的Team Builds节点，决定定义了那些Team Build类型。呈交的每一个节点都能够用来剔除一个生成。
Team Foundation Server利用指定的生成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分析器强大功能的冰山一角，它们还能够订制用来满足你的特殊须要，订制方法也非常easy，只须要为你的server部署一个新的报告 就可以。
小结
在本文的两个部分中，我们介绍了Team Foundation Server的几个关键特性领域，包含过程管理，工作项跟踪，版本号控制，自己主动生成和报告。由于TFS是一个庞大的产品，因此我们不可能仅在一篇文章中对每 个特性都给出具体的介绍，更不用说伴随各个版本号Visual Studio 2005的client特性。希望本文可以抛砖引玉，使你对该产品的功能以及对开发小组带来的故意之处有所了解。
在你决定使用微软的产品，定购Team Foundation Server之前，你须要看看这个工具是否适合你。为此，我给大家提供以下关于该产品的优缺点列表供參考。
