在本文的两个部分中，我将介绍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，如下图。

文件夹添加到版本控制系统后，其他的程序员并不会立即看到，他们必须像文件一样进行注册。在本例中，在注册前我将添加一组解决方案和项目文件到。

版本控制系统和工作项存储器在注册时集成在一起。当注册时，可以将其与一个或多个工作项关联。例如，因为这是刚引入源代码，所以我可以浏览注册对话框中的工作项视图，选择工作项3387和它关联。注意当关联工作项时无论默认的选择如何都要将注册行为设定为 “解决”，这样做的目的是防止任务关闭工作项，因此较早建立十分有用的Recycle Bin 查询。

建立一个注册，就叫做一个改变集，一个源代码容器不过是一系列不断彼此堆积起来的改变集。因为在数据库中改变集是一个可以区分的实体，因此可以将数据和它关联在一起，所以上面建立的改变集和工作项3387的关系可以在改变集中浏览或者在工作项中浏览。下面的屏幕截图显示了连到工作项的改变集。

新概念：搁置集

和Team Foundation Server中的版本控制相关的一个新概念是搁置集。搁置集的思想是程序员在过周末休息时，可以将在工作日做的改变放在某个安全的地方。建立一个搁置集相当简单，首先，程序员在解决方案浏览器中的背景菜单中选择“搁置必要的改变”，然后出现下面的对话框。

程序员可以给搁置集一个名字，以便以后可以查找和恢复它，和注册对话框一样，搁置集也可以添加评论和关联工作项。搁置集仅包含修改过的文件，因为改变集版本是从版本控制存储器引出的，所以创建他们的相当简单。

为了恢复搁置集，可以选择背景菜单中的“解冻必要改变”选项，程序员可以查找由他们或其他程序员建立的搁置集。

事实上搁置集可以共享，这意味着它们可以很好的执行代码预览，增强单注册点策略，这对一个特别项目在封装时可能很十分有用。

在本文的下一部分，我将详细介绍搁置集，TFS中完善的分支支持，TFS是如何支持自动生成的并介绍一下报告功能提供的功能。