在本文的两个部分中,我将介绍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是怎样支持自己主动生成的并介绍一下报告功能提供的功能。
功能介绍一:微软最新配置管理工具
在当今的环境下,公司业务越来越复杂,软件开发复杂度也越来越高,此时发如今众多项目中时有这种现象发生:文档散落在不同地方,代码缺失,代码和文档不一致,同一系统多个版本号,各项目採用不同配置管理工具、无统一的规范,随着时间推移我们的项目管理风险不断上升、项目实施难度不断添加、项目实施质量难以掌控。怎样可以高速地构造出高质量的应用系统来满足不断变化的业务增长所带来的需求?我们急须要建立一套完好的配置管理体系,来提高生产效率,提高产品质量,终于实现企业效益最大化。现阶段配置管理面临的挑战是:功能介绍二:外包管理工具