大家好，又见面了，我是全栈君，祝每个程序员都可以多学几门语言。
在本文的两个部分中，我将介绍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的连接。
创建团队项目时，开发小组须要做的第一件事情是决定使用那个开发模型。
选择开发模型
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是怎样支持自己主动生成的并介绍一下报告功能提供的功能。
功能介绍一：微软最新配置管理工具
在当今的环境下，公司业务越来越复杂，软件开发复杂度也越来越高，此时发如今众多项目中时有这种现象发生：文档散落在不同地方，代码缺失，代码和文档不一致，同一系统多个版本号，各项目採用不同配置管理工具、无统一的规范，随着时间推移我们的项目管理风险不断上升、项目实施难度不断添加�、项目实施质量难以掌控。怎样可以高速地构造出高质量的应用系统来满足不断变化的业务增长所带来的需求？我们急须要建立一套完好的配置管理体系，来提高生产效率，提高产品质量，终于实现企业效益最大化。现阶段配置管理面临的挑战是：
l 统一的规范
l 更好的组织性，更高的开发管理水平
l 保护投资 ：企业级的过程历史数据、经验、数字化资产
l 建立标准的开发环境
l 实现并行开发，缩短产品面市时间
l 自己主动化管理
l 为创造性的工作释放很多其它的时间
l 员工更加专业
而通过微软的Team Foundation Server（TFS）实施软件配置管理可以有效解决这些问题，比如可以集中管理各项目的文档、代码，对项目中的文档、代码等的变化进行有效管理，可以方便地重现某个文件的历史版本号，可以又一次编译某个历史版本号，使文档维护工作变得easy、可以使多团队并行开发成为现实，同一时候实行统一的配置管理流程可提高项目组间人员流动时的工作效率，也是对工作成果的一种有效保护。
功能介绍二：外包管理工具
随着信息技术的飞速发展，软件已进入了社会生活的方方面面，越来越多的企业将他们的业务系统构建在以软件为核心的系统之上，企业通过它们来为自己的客户提供高速优质的服务。正由于软件已经成为业务的基础平台，企业的核心竞争力在非常大程度上取决于软件系统的质量，要求软件系统可以迅速适应业务需求的变化，同一时候保证软件系统的高性能、高可靠性和可维护性。然而对于大部分企业而言，软件开发并非他们所擅长的业务，加上软件系统的复杂性及非常高的质量要求，大部分企业都选择将软件开发项目外包出去，由专业的软件开发（供应）商来负责软件的开发。可是软件外包并不意味着企业对于软件的开发过程放手无论，企业应该建立与供应商之间的协议，而且监控供应商的开发过程，并对供应商提交的终于系统进行全面的验收，从而彻底保证供应商可以按时交付一个高质量的软件系统。
软件项目的成败在非常大程度上取决于对其开发过程的控制，这包含对质量、源码、进度、资金、人员等的控制。要进行有效的过程控制，只依靠人的力量是不够的，还须要有对应的管理工具支持以实现高效的“软件生命周期管理”。然而因为历史和现实的原因，软件生命周期管理流程和工具在我国软件行业中的应用并不普及，因为缺乏必要的管理流程和工具，非常多企业在软件外包项目中都会或多或少的遇到例如以下的问题：l 缺少统一的开发管理流程指导，无法保证项目的质量和成功率
l 开发出来的系统不能满足用户或者业务需求
l 开发过程不透明，非常难监控开发的进展情况
l 不能及时了解项目的 进度，常常导致项目延期
l 无法有效的控制项目的变更，添加�了项目的风险
l 无法有效实现多地的协同开发 ，添加�外包开发成本（场地，差旅费）
l 软件复用率低下，减少了企业的投资回报率
l 无法开展规范化的測试工作 ，非常多问题要到验收阶段才会暴露出来
l 缺乏软件开发历史数据的积累， 无法准确估算项目成本
l 缺乏必要的版本号管理工具，系统在构建和公布时产生问题
l 缺乏对应的文档，添加�了维护和升级的难度
这些问题导致非常多企业对外包项目不能进行有效的控制或是在开发中造成过多的资源浪费（各个系统间太多的反复开发），以及开发出来的系统不能响应市场高速的变化。这些问题直接减少了发包方企业的生产力，添加�了企业运营成本。要从根本上切实提高软件外包开发的管理水平，必须从多方面入手，引入先进的开发流程，借鉴业界的最佳实践，以及构筑高效的系统开发管理平台是必定的选择。
为了解决上述的外包开发管理中的常见问题，我们基于微软最新公布的软件生命周期工具，设计了微软的软件外包开发管理解决方式，可以对多平台和地理分布的开发团队提供必要的开发流程指导，实现高效的项目管理，促进项目团队的沟通，并提供了紧密集成的变更和配置管理系统，为企业建立了先进的软件协同开发管理平台。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/118314.html原文链接：https://javaforall.cn
