使用tfs进行团队开发 - 第一部分

使用 Visual Studio Team Foundation Server 进行 团队开发

本书共分四部分，此为第一部分 包括基础知识、源代码管理、生成、大型项目考虑事项 项目管理、过程指南、报告、设置和维护团队环境和 Visual Studio 2008 Team Foundation Server等九章节

使用 Visual Studio Team Foundation Server 进行团队开发

模式与实践

J.D. Meier Jason Taylor Alex Mackman Prashant Bansode Kevin Jones

本文档中的信息（包括 URL 和其他 Internet 网站引用）如有更改，恕不另行通知。除非另有声明，否则此处 描述的示例公司、组织、产品、域名、电子邮件地址、徽标、人物、地点和事件都是虚构的，无意与任何真实 的公司、组织、产品、域名、电子邮件地址、徽标、人物、地点或事件相关联，也不应进行这方面的推断。遵 守所有适用的版权法律是用户的责任。未经 Microsoft Corporation 明确的书面许可，不得出于任何目的或以 任何形式或任何手段（电子、机械、复印、记录或其他方法）复制本文档的任何部分，或者将其存储或引入检 索系统，或者将其进行传播。受版权法保护的权利不受此限制。 对于本文档中的主题，Microsoft 可能具有专利、专利申请、商标、版权或其他知识产权。除非 Microsoft 的任 何书面许可协议明确提出，否则，本文档的提供并不表示 Microsoft 已将这些专利、商标、版权或其他知识产权 的任何许可权限授予您。

© 2007 Microsoft Corporation。保留所有权利。 Microsoft、MS-DOS、Windows、Windows NT、Windows Server、Active Directory、MSDN、Visual Basic、 Visual C++、Visual C#、Visual Studio 和 Win32 是 Microsoft Corporation 在美国和/或其他国家或地区的 注册商标或商标。 本文档中提及的所有公司和产品属于其各自所有者的商标。

Jeff Beehler 撰序 序言 发布 Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) 之前，我们自己先进行了一次尝试— —使用它来开发 TFS。在项目的最后 18 个月中，我们尽可能地应用它来管理项目的开发生命周期，这 也就是所谓的“Dogfooding”（内测）。通过这种内部先行试用，我们对自己创建的这一强大系统有了更 多的认识。我们确实发现并修复了很多质量问题，使最终产品更稳定、性能更高，如果不使用这种方法， 根本无法做到这一点。但更重要的是，我们更清楚了使用这种工具的最佳方式。这些经验与客户体验反 馈一起构成了这份指南的基础。 初看起来，读者可能认为这些信息应该属于产品文档的内容，甚至就可以取代产品文档。实际上，我 曾经也有过这种想法。然而，在与 J.D. Meier 和本指南的其他作者协作工作了一段时间后，我就清楚 地认识到，这两者的区分是很自然而且很重要的。我认为将这两份指南比作您的车主手册和驾驶员指 南再恰当不过了，两者都是必要的，但其目的又各有不同。按照惯例，产品团队只关注产品文档，而 将指导方面的工作留给其他人员。现在尽管我们依然要依靠其他人员来帮助解决问题，但已经开始在 指南部分投入更多的时间和精力，因为我们意识到产品的成功采用的重要性，以及它在提高整体客户满 意度方面的意义。 TFS 就如同汽车，是一种强大的工具，能够帮助您和您的团队更接近目标，这份指南则会帮助您实现 目标。每个团队根据其具体需求和历史情况的不同，都会以不同方式或多或少地接触 TFS。出于这方 面的考虑，我们撰写这份指南时采用了这样一种方式：即如果您希望了解全部内容，可以从头读到尾； 如果只需要部分指导，也可以细读具体的主题。 客户反馈是我们撰写这份指南的最初动力，今后也将一直引导我们的方向，并帮助我们实现目标。我们 深信，与闭门造车相比，像这样将社区纳入项目之中能够使内容更有用，最终使我们的指南更加成功。 按照这种思路，真正的用户将帮助我们决定要写哪些内容、要推荐哪些最佳实践，以及如何组织内容。 我们的收集整理工作尚未完成，请帮助我们继续改进这份指南，告诉我们您还希望本指南中涵盖哪些内 容。TFS 的覆盖面如此广泛，有时甚至连我们也觉得难以全面掌握。有了您的加入，我们就可以帮助客 户更好地利用我们所开发的工具。 TFS 的设计目的是使团队协力交付更好的软件。通过在内部先行试用 TFS，我们已经使自己的团队协同 工作，我希望您也会同意，这就是最好的成果。这份指南能够帮助您和您的团队在下一个项目中实现此 远景。 祝您一切顺利！

Jeff Beehler 主管，Visual Studio Team System 2007 年 7 月 Jeff Beehler 是 Team System 的主管。从科罗拉多大学毕业之后，他于 1990 年在 Microsoft 开始了自 己的职业生涯，最初致力于 Visual C++ 的早期版本。1996 年，他离开了 Microsoft，转向自己的其他 兴趣所在，包括咨询、在小学教学，还建立了自己的家庭。2003 年，他回到了 Microsoft，从事 Visual Studio Team System 方面的工作，在这里，他参与了项目的多个方面，从规划、执行一直到发布。他积 极参与 Team System 各个部分的内部先行试用工作，这有助于进一步提高他的职业技能。在业余时间， Jeff 喜欢与家人分享时光、摄影以及在西部地区参与户外运动。

Rob Caron 撰序 序言 自 Visual Studio Team System 问世以来，我们就知道，软件开发团队需要的内容比我们在发布之前提供 的内容要多的多。具体来说，我们知道他们需要经过证实的指南和最佳实践，但是，只有产品已经深入 应用于大量团队的多种环境、项目和方案并经过验证后，我们才可能得到这些知识。 遗憾的是，经过证实的指南和最佳实践的确认与开发需要时间。在过去几年，我们已经掌握了大量关 于 Team System 使用的知识，特别是 Team Foundation Server。但那些知识并非总是能够轻松发现和理 解。模式与实践方面的行家 J.D. Meier 及其团队为此付出了好几个月专注、系统化的工作。 最终，漫长的等待结束了！ “使用 Visual Studio Team Foundation Server 进行团队开发”代表了直接或间 接无数为此项目作出贡献的工作人员的集体智慧。组织这些内容的团队并未忽略先驱者的经验。他们在 分散的博客文章、论坛文章、论文等资料中精挑细选，以更好地理解团队是如何“自由”采纳和使用 Team System 的。 在这个过程中，他们观察了影响软件开发团队的关键领域；确认了哪些实践能够带来可预测、可重 复的成功。部分信息最丰富的内容解释了许多 Team Foundation Server 功能领域，如工作项跟踪、报 告和过程模板。 回想起来，我很高兴自己能够成为文档团队的一员，能够耐心地将这项工作延后，而不是试图提供充 满“最佳猜测”的内容。我向在没有这些内容的情况下苦苦煎熬的所有人道歉，还要感激不屈不挠的 Team System 早期用户。 Rob Caron 首 席 产 品 经 理 ， Microsoft Corporation，2007 年 7 月 Rob Caron 是 Microsoft Developer Content Strategy 的首席产品经理。Rob 于 1999 年作为 Visual Studio 产品文档作者加入 Microsoft。多年来，他为 Visual Studio .NET 2002、Visual Studio .NET 2003 和 Visual Studio Team System 的内容均作出了自己的贡献。在 2004 年中期，他建立了自己的博客，其博客现已 成为 Team System 相关信息的中转站。从事内容创建工作七年以后， Rob 在 2006 年秋季调入 Developer Marketing 团队。现在，他率领着一支小组，集中关注 Microsoft 越来越复杂的开发者形势，

并以简化这种形势为目标。

前言 这份指南介绍如何更好地利用 Visual Studio 2005 Team Foundation Server 来帮助改进基于团队的软件 开发的效率。无论您是 Team Foundation Server 的老用户还是新用户，都会找到适于您具体情况的指南 和深入见解。 本指南中的信息源自客户和产品支持部门的反馈，以及从现场实际工作中获得的经验。本指南按照任务 编写，分为以下几部分。 z

第 I 部分： “基础知识” ，使用 Team Foundation Server 进行团队开发的概述。您将看到软件开发 环境方面的全景，包括开发和测试环境。您还会了解 Team Foundation Server 的基本体系结构。

z

第 II 部分： “源代码管理”，介绍如何设置源代码的结构以及如何管理依赖关系。此外还会介绍 在需要分隔开发工作时，应怎样确定分支和合并策略。

z

第 III 部分： “生成” ，向您展示如何设置团队生成、如何为开发团队提供连续集成生成、如何为 测试团队提供预定生成。此外还讨论了常见问题及其解决方法。

z

第 IV 部分： “大型项目考虑事项” ，介绍了在致力于大型项目时需要处理的其他考虑事项。

z

第 V 部分： “项目管理” ，介绍了如何使用 Team Foundation Server 工作项、区域及其迭代来简化 开发过程，无论您使用的是哪种项目管理方法。

z

第 VI 部分： “过程模板” ，介绍了如何更好地利用随 Team Foundation Server 提供的开箱即用过程 模板和过程指南。此外还介绍了如何自定义过程模板、修改工作项和工作流来映射团队已经使用的 软件工程过程。

z

第 VII 部分： “报告” ，介绍了其他所有 Team Foundation Server 组件是如何将其数据存储集成到 公共报告机制中的。您将了解如何使用默认报告以及如何生成您自己的自定义报告。

z

第 VIII 部分：“设置和维护团队环境”，揭秘 Team Foundation Server 部署。您将了解如何在 单服务器和多服务器部署间作出选择。还会了解如何支持远程开发团队以及如何最大化 Team Foundation Server 的性能。

z

第 IX 部分： “Visual Studio 2008 Team Foundation Server”，介绍了下一版 Team Foundation Server 中将出现的变更。您将了解计划中的新功能，以及哪些功能会得到大幅度改进。部分更改会影响本 指南中其他位置给出的指导，因此请使用本节配合您的 Team Foundation Server 升级计划。

z

指南，提供关于 Team Server 生成、项目管理、报告和源代码管理的简明建议。每份指南都 会告诉您要做哪些事情、为什么要遵从指南以及如何遵从指南。

z

实践，以课程开发团队通过现场和 Microsoft 内部的 Team Foundation Server 应用掌握的经验教 训为基础，提供一组最佳实践。每项实践均关注如何完成一个对于团队有效使用 Team Foundation Server 至关重要的任务。

z

问题与解答，提供 Team Foundation 源代码管理相关常见问题的解答。

z

如何，提供如何使用 Team Foundation Server 完成特定任务的深入、详尽指南。

z

资源，Web 站点、服务供应商、论坛和博客一览表，可用于进一步了解 Team Foundation Server， 掌握该工具集的最新发展动向。

团队开发 为实现成功的、基于团队的软件开发项目，有多种元素、过程和角色结合在一起。这份指南主要关 注：

z 开发过程 z 生成过程 z 项目管理过程 下图展示了与团队开发相关的典型软件开发过程间的关系，以及可如何利用 Team Foundation Server 来 为这些计划提供水平基础。

团队开发 项目管理 开发过程

生成过程 Team Foundation Server

版本 控制

生成 服务器

工作项

项目 门户

报告 和 分析

本文范围 这份指南主要关注部署 Team Foundation Server 和有效地使用它来进行源代码管理、生成自动化、工作 项管理和过程管理。 下图概括了 Team Foundation Server 的一个示例逻辑实现，在图中，它与软件工程和开发生命周期中 最常见的角色关联。

团队

Team Foundation Server

应用层 项目经理

开发人员

z z z z z z z

项目门户 源代码管理 生成自动化 工作项 项目管理 报告 集成服务

数据层

数据库

测试人员 Team Build Server

Team Foundation Server Proxy 远程团队

本文初衷 根据我们自己的 Team Foundation Server 经验、与客户和 Microsoft 现场工作人员的沟通，我们认为有 必要编写一份指南，展示如何在现实中使用 Team Foundation。虽然产品文档、博客文章、论坛文章中 提供了一些信息，但尚无一个集中的位置可以找到全部经过验证的实践，在考虑到现实制约因素的开发 项目的上下文中有效利用 Team Foundation Server。

读者对象 本指南的目标在于为参与软件开发过程的人员提供资源、模式和实践，从而创建有效的团队开发环 境。下面是能从本指南受益的部分角色： z z z z

希望采纳 Team Foundation 的开发团队。 期望从 Team Foundation 中获得关于管理项目和开发工作、提供软件开发计划的状态、为企业利益 相关人提供反馈的最大收益的项目经理。 投资使用 Team Foundation，却不知道它对自己的开发方案和团队效果如何的相关人员。 肩负规划部署和安装 Team Foundation 任务的人员。

如何使用本指南 本指南根据我们看到的大多数团队考虑和采纳 Team Foundation 时的顺序划分为几大部分。如果您正处

于采纳 Team Foundation 的过程中，那么很可能希望从头至尾阅读整个指南。如果您对 Team Foundation 的某种特定用途感兴趣，例如源代码管理或团队生成，那么可以仅阅读相关部分。利用主要章节来学习 概念和指导原则。利用附录“指南” 、 “实践” 、 “如何”文章与“问题与解答”来钻研实现细节。这种划分 使您能够首先理解主题，然后再钻研恰当的细节。

本文组织方式 您可以从头至尾阅读本指南，也可以根据工作的需求选取特定章节阅读。

部分 本指南划分为九大部分： z 第 Ⅰ 部分：基础知识 z 第 Ⅱ 部分：源代码管理 z 第 Ⅲ 部分：生成 z 第 Ⅳ 部分：大型项目考虑事项 z 第 V 部分：项目管理 z 第 VI 部分：过程指南 z 第 VII 部分：报告 z 第 VIII 部分：设置和维护团队环境 z 第 IX 部分：Visual Studio 2008 Team Foundation Server 第 Ⅰ 部分：基础知识 z 第 1 章 – 团队环境简介 z 第 2 章 – Team Foundation Server 体系结构 第 Ⅱ 部分：源代码管理 z 第 3 章 – 在源代码管理中设计项目和解决方案的结构 z 第 4 章 – 在 Team Foundation 源代码管理中设计项目和解决方案的结构

z z

第 5 章 – 定义分支和合并策略 第 6 章 – 在 Visual Studio Team System 中管理源代码管理依赖项

第 Ⅲ 部分：生成 z 第 7 章– Team Build 简介 z 第 8 章–使用 Team Build 设置连续的集成 z 第 9 章–使用 Team Build 设置预定生成 第 Ⅳ 部分：大型项目考虑事项 z 第 10 章：大型项目考虑事项 第 V 部分：项目管理 z 第 11 章 – 项目管理简介 z 第 12 章 – 工作项简介 第 VI 部分：过程模板 z 第 13 章 – 过程模板简介 z 第 14 章 – 用于敏捷软件开发项目的 MSF 第 VII 部分：报告 z 第 15 章 – 报告简介 第 VIII 部分：设置和维护团队环境 z 第 16 章 – Team Foundation Server 部署 z 第 17 章 – 提供 Team Foundation Server 的 Internet 访问 第 IX 部分：Visual Studio 2008 Team Foundation Server z 第 18 章 – Visual Studio 2008 Team Foundation Server 新功能

指南： z z z z

指南：团队生成 指南：源代码管理 指南：报告 指南：项目管理

实践 z z z z

报告团队生成 报告源代码管理 报告报告 报告项目管理

问题与解答： z

问题与解答：Team Foundation Server 源代码管理和版本控制

“如何”文章 z 如何：在 Visual Studio Team Foundation Server 中为您的项目增加新开发人员 z 如何：使用 Team Build 在 Visual Studio Team Foundation Server 中自动运行代码分析 z 如何：为 Visual Studio Team Foundation Server 创建自定义报告 z 如何：为 Visual Studio Team Foundation Server 创建长期风险报告（Risk Over Time Report） z 如何：在 Visual Studio Team Foundation Server 中创建自定义签入策略 z 如何：在 Visual Studio Team Foundation Server 中创建源代码树 z 如何：在 Visual Studio Team Foundation Server 中自定义过程模板 z 如何：在 Visual Studio Team Foundation Server 中自定义报告 z 如何：在 Visual Studio Team Foundation Server 中管理项目 z 如何：将 Visual Source Safe 中的源代码迁移到 Team Foundation Server z 如何：在 Visual Studio Team Foundation Server 中执行 Baseless 合并 z 如何：在 Visual Studio Team Foundation Server 中设置连续集成生成 z 如何：在 Visual Studio Team Foundation Server 中设置预定生成 z 如何：在 Visual Studio Team Foundation Server 中设计 ASP.NET 应用程序的结构 z 如何：在 Visual Studio Team Foundation Server 中设计 Windows 应用程序的结构 z 如何：在 Visual Studio Team Foundation Server 中设计源代码管理文件夹的结构

资源 z

Team Foundation Server 资源

反馈和支持 我们已经竭尽所能保证本指南及其附属内容的准确性。

关于本指南的反馈 如 果 您对 本 指 南有 任 何 意见 ， 请 将邮 件 发 送 到 TFSguide@microsoft. com。 我们对与以下内容相关的反馈特别感兴趣： z 特定于建议的技术问题 z 有效性和实用性问题

技术支持 对本文中提到的 Microsoft 产品与技术的支持由 Microsoft Product Support Services (PSS) 提供。关于产品 支持信息，请访问 Microsoft Product Support Web 站点，地址为：http://support.microsoft.com。

社区支持 MSDN 新闻组： http://forums.microsoft.com/MSDN/default.aspx?ForumGroupID=5&SiteID=1 论坛

地址

Team Foundation Server -概http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=22&SiteI D=1 述

Team Foundation Server - http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=68&SiteI D=1 Setup Team Foundation Server –http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=477&Site ID=1 Administration Team Foundation Server -生http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=481&Site ID=1 成自动化 Team Foundation Server - http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=930&Site ID=1 Power Toys Team Foundation Server –http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=482&Site ID=1 Process 模板 Team Foundation Server -报http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=480&Site ID=1 告数据仓库 Team Foundation Server –http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1466&Sit Team System Web Access eID=1 Team Foundation Server Version 控制

http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=478&Site ID=1

Team Foundation Server -工http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=479&Site ID=1 作项跟踪

本文创作团队 本指南由以下团队成员创作： z J.D. Meier z Jason Taylor z Alex Mackman z Prashant Bansode z Kevin Jones

贡献者和审阅者 z

z

外部贡献者/审阅者。David P. Romig；Sr; Dennis Rea；Eugene Zakhareyev；Leon Langleyben； Martin Woodward；Michael Rummier；Miguel Mendoza；Mike Fourie；Quang Tran；Sarit Tamir； Tushar More；Vaughn Hughes Microsoft 贡献者/审阅者。Aaron Hallberg；Ahmed Salijee；Ajay Sudan；Ajoy Krishnamoorthy； Alan Ridlehoover；Alik Levin；Ameya Bhatawdekar；Bijan Javidi；Bill Essary；Brett Keown；Brian Harry；Brian Moor；Brian Keller；Buck Hodges；Burt Harris；Conor Morrison；David Caufield； David Lemphers；Doug Neumann；Edward Jezierski；Eric Blanchet；Eric Charran；Graham Barry； Gregg Boer；Janet Williams Hepler；Jeff Beehler；Jose Parra；Julie MacAller；Ken Perilman；Lenny Fenster；Marc Kuperstein；Mario Rodriguez；Matthew Mitrik；Michael Puleio；Nobuyuki Akama； Paul Goring；Pete Coupland；Peter Provost；Granville (Randy) Miller；Rob Caron；Robert Horvick； Rohit Sharma；Ryley Taketa；Sajee Mathew；Siddharth Bhatia；Tom Hollander；Tom Marsh；Venky

Veeraraghavan

与我们分享您的成功 如果这份指南对您有帮助，我们很希望知道。请将您面临的问题编写成一份简单的汇总，并写清楚这份指 南是如何帮助您解决问题的。将您的汇总内容提交到：My Story @Microsoft. com。

第 I 部分 基础知识 本节内容： ¾

团队环境简介

¾

Team Foundation Server 体 系 结 构

第 1 章 – 团队环境简介 目标 z z z z

描述 Microsoft® Visual Studio® Team Foundation Server 是如何为软件开发生命周期提供支持 的。 介绍典型的开发团队如何使用 Team Foundation Server。 介绍典型的测试团队如何使用 Team Foundation Server。 介绍开发和测试环境的物理环境。

概述 本章介绍如何在基于团队的软件开发环境中使用 Team Foundation Server (TFS) 和 Microsoft Visual Studio Team System (VSTS)。简要介绍了 TFS 和 VSTS 的核心功能，还展示了软件开发项目中开发和 测试团队间的工作流。由于 TFS 集成了源代码管理、工作跟踪、报告、项目管理和一个自动化的生成 过程，因此使一支开发团队能够更加有效地协作。 成功的基于团队的软件开发项目具有许多过程，这些过程必须彼此平稳协作来确保得到一个有效的工作 环境。核心过程包括： z z z z z

开发 测试 生成 部署 发布

本章为您介绍了开发和测试团队可使用 TFS 执行的典型功能，还说明了能够如何利用 TFS 来管理工 作流，为跨团队的有效协作提供支持。

如何使用本章 使用本章来了解 TFS 是如何设计为支持软件开发生命周期的。通过阅读这一章，您还会掌握 TFS 工 作流以及 TFS 是如何使您能够改进团队协作的。 关于 TFS 体系结构和 TFS 核心组件的更多信息，请参见“第 2 章 - Team Foundation Server 体系结 构”。

Team Foundation Server 的逻辑工作流 TFS 使开发团队能够将代码存储在一个集中管理的源代码存储库中。可以使用生成服务器，通过此存 储库创建生成，随后可以将这些生成分发给测试团队。 图 1.1 展示了 TFS 的逻辑工作流以及开发和测试团队是如何连接在一起的。

项目主管 数据 分人员

Team Foundation Server 开发环境

生成号 =1.0.60712.0

放置点

Select

测试环境 功能测试 系统测试

生成号 =1.0.60713.0

Dev+单元测试

测试 客户端

生成号 =1.0.60714.0

Dev PC

TFS 源代码 存储库

TFS 生成系 统

生成号 =1.0.60715.0 测试结果 数据库

Bug 工作项

跟踪 数据库

测试结果 (.trx) 上载 Bug 工作项

图 1.1 Team Foundation Server 逻辑工作流 测试团队从一个放置位置 (drop location) 拾取生成，并通过结合执行手动和自动测试的方法在整个测试 环境中运行这些生成。测试结果由 TFS 存储，并用于提供生成质量反馈。测试团队还可以创建工作项和 bug（工作项的一种具体类型），开发团队需要对其加以处理。这些工作项允许测试团队跟踪开发团队的 工作。

开发、测试和生产环境的逻辑工作流 在具有多个开发团队的大型组织中，每个开发团队都维护一个单独的 TFS，包括单独的源代码存储库和 团队生成服务器。图 1.2 展示了两个开发团队将应用程序生成交付给一个测试团队的逻辑工作流。

Dev 团队 X Dev 数据库服务器

放置点

QA 团队 稳定生成

最终检查

QA

Dev PC

源代码 存储库

发布

部署

自动生成

生产环境

登台环境

登台 服务器

资源 存储库

生成 服务器

Dev 团队 Y Dev 数据库服务器

放置点

测试环境 功能测试 系统测试

Dev PC

源代码 存储库

自动生成

测试客户端 PC

测试结果 上载 注册 bug

测试结果存 储库 bug 跟踪数 据库

bug 反馈

图 1.2 展示两个开发团队和一个集成的测试团队的逻辑工作流 每个开发团队均将预订生成交付到一个放置点，如网络共享。这些生成由测试团队拾取，用于测试生成 的质量。测试质量这一大关通过之后，应用程序即可部署到一个登台服务器，供最终检查和用户验收， 最后部署到生产服务器上。

开发过程 开发人员在软件开发项目的整个过程中执行一系列与 TFS 的关键交互。例如，作为一名开发人员， 您要通过以下几种方式与 TFS 交互： z z z z z

访问 TFS 中的 bug 和任务工作项，以确定您需要完成哪些工作。例如，您的项目经理、另一名 开发人员或者测试团队可能已经分配了工作项。 您使用“VSTS 源代码管理资源管理器”来访问 TFS 源代码管理存储库，并将最新的源代码拉取 到本地工作区或您的开发计算机中。 执行了工作项标识的工作之后，重新将代码签入到源代码管理数据库中。 签入事件触发使用 Team Build 的连续集成生成。 如果生成失败，则创建一个新工作项来跟踪生成中断。

测试过程 作为测试团队的一名成员，您要通过以下几种方式与 TFS 交互： z 从特定放置位置拾取预定生成的输出。 z 通过使用各种 VSTS 工具执行手动和自动测试，包括安全测试、性能测试和 Web 测试。 z 将测试得到的结果上载到 TFS 测试结果数据库，以便将来参考。 z 将测试识别出的 bug 作为新工作项记录到 TFS 中。

z

如果最新的生成修订了之前记录的 bug，您就要解决现有 bug。

开发和测试物理环境 与开发和测试环境相关联的计算机规格和数量根据团队、项目的大小而有所不同。图 1.3 展示了典型的 开发和测试物理环境。 Dev 域 活动目录 BizX Dev Team

测试域 活动目录 Rig

测试团队 (QA 团队)

中央 存储库

代理 测试环境

控制器 开始

TFS

测试人员 手动 测试文档

测试脚本 Dev Web 服务器

TFS 生成 测试结果 放置点

部署

Ver.1.0.60712.0 部署

Ver.1.0.60713.0 Ver.1.0.60714.0 部署

生产域 活动目录

图 1.3 开发和测试物理环境 开发环境 开发环境为您的开发和生成过程提供支持。开发环境包含以下计算机： Team Foundation Server。 生成服务器。 用于存储生成服务器放置结果的服务器。 开发人员工作站。

如果您的开发团队远程访问 TFS，或者有一个规模庞大的团队导致了中央 TFS 服务器的性能问题，也 可以设置一个 TFS 代理来帮助改进性能。

测试环境 测试环境包含一个或多个安装了 Visual Studio Team Edition for Software Testers 的测试工作站。这用于 管理测试生命周期，以及执行功能测试、系统测试、安全测试、性能测试和 Web 测试。团队成员使用

TFS 来管理工作项、bug 和测试结果。 测试环境还可能包含 Visual Studio Team Test Load，用于性能测试。

小结 VSTS 和 TFS 设计用于支持软件开发生命周期，它集成了软件开发的方方面面，例如源代码 管理、工作跟踪、报告、项目管理和自动生成过程。 TFS 在测试与开发团队间的协作中扮演着重要的角色。开发团队在整个开发周期内与 TFS 交互，访 问 bug 和工作项以确定需要完成哪些工作、访问源代码管理以支持开发。测试团队与 TFS 交互来运 行测试、上载测试结果、记录 bug。

其他资源 z

关于更多 TFS 基础知识，请参见“Team Foundation Server 入门：功能与体系结构简介”， 地址为：http://msdn2.microsoft.com/en-us/library/ms3 64062(vs.80).aspx

z

关于 Team Foundation 的概述，请参见 Microsoft MSDN® Web 站点上的 Team Foundation 产 品文档，地址为：http://msdn2.microsoft.com/enus/library/ms 181 232(vs.80).aspx

第 2 章 - Team Foundation Server 体系结构 目标 z z z

介绍 Microsoft® Visual Studio® Team System (VSTS) 和 Team Foundation Server (TFS) 体系结 构。 识别构成客户层、应用层和数据层的组件。 强调单服务器和多服务器部署间的差别。

概述 本章简要介绍了 TFS 体系结构和基本的部署拓扑。TFS 具有逻辑三层体系结构，包括客户层、应用 层和数据层。TFS 客户端通过各种 Web 服务与应用层交互；应用层使用数据层中的各种 Microsoft SQL Server™ 数据库。 可以选择将应用层和数据层安装在同一台物理服务器上，也可选择分别安装在单独的服务器上。您的选 择很大程度上要取决于团队的规模。单服务器部署非常适合团队成员少于 50 人的团队，但若使用一 台足够强大的服务器，最多可以支持 400 个用户。双服务器部署可以上扩到支持约 2000 个用户。

如何使用本章 使用本章来了解核心 TFS 组件及其彼此间的交互方式。通过阅读这一章，您还会掌握所有这些组件的 用途以及它们为什么是最常用的部署组件。 如果您刚刚接触 TFS，应该首先阅读“第 1 章 – 团队环境简介”，了解开发和测试团队如何通过 TFS 交互，以及如何利用它来改进协作和软件开发工作的整体成效。

Team Foundation Server 体系结构 TFS 利用了一种逻辑三层体系结构，包括客户层、应用层和数据层。TFS 客户端通过各种 Web 服务与 应用层交互；应用层又通过数据层中的各种数据库得到支持。图 2.1 展示了 TFS 各层组件及其交互。

客户层 Visual Studio Office 2005 （加载项）

命令行

其他

Internet Explorer

Team Foundation 客户端 API（对象模型）

WSS

应用层

ASP.NET Team Foundation Web 服务 Team Foundation

Team Foundation 集成服务 事件和 通知服务

数据层

链接 服务

Team Foundation 数据服务

注册 服务

工作项 服务

源代码 管理服务

生成 数据服务

团队项目门户站 点 Web 部件 SQL 报表服务 报告

SQL Server 2005

工作项

方法学

生成数据

数据仓库

源代码存 储库

图 2.1 TFS 组 件 和 层

客户层 客户层包含以下重要组件 z z z

z z

Team Foundation Server 对象模型。这是用于与 TFS 交互的公共 API。您可以使用这个对象模 型来创建自己的客户端应用程序，与 TFS 交互。 Visual Studio Industry Partners (VSIP) 组件。供在 Visual Studio 内使用的第三方工具、加载 项和语言。 Microsoft Office 集成。包含一组用于 Microsoft Office Excel® 和 Microsoft Office Project 的加载 项，使您能够查询和更新 TFS 工作项跟踪数据库中的工作项。对于已经在广泛应用这些工具的项 目经理来说，这特别有用。 命令行工具。使您能够通过命令行与 TFS 交互的工具。大多数此类工具都提供了源代码管理 功能，它们对于自动化重复任务和预定任务是非常有用的。 签入策略框架。支持签入策略功能，即一种可扩展的机制，使您能够在签入过程中验证代码。

应用层 应用层公开以下这些可由客户层访问的 ASP.NET Web 服务。这些 Web 服务的目的并非是供第三方集 成商据以编程，此处介绍是为了保证完整性。Web 服务组织为以下集合： Team Foundation 数据服务 Team Foundation 集成服务

Team Foundation 数据服务 这组 Web 服务主要关注在数据层中操纵数据。这些服务包括： z 版本控制 Web 服务。客户层使用此 Web 服务来执行各种 TFS 源代码管理功能并与源代码管理 数据库交互。

z z

工作项跟踪 Web 服务。客户层使用此 Web 服务来创建、更新和查询工作项跟踪数据库中的工作 项。 Team Foundation Build Web 服务客户层和 MSBuild 框架使用此 Web 服务来执行生成过程。

Team Foundation 集成服务 这组 Web 服务提供集成和自动化功能。这些服务不与数据层交互。Team Foundation 集成服务 包括： z 注册 Web 服务。此服务用于注册其他各种 TFS 服务。它维护一个注册数据库中的信息。服务 使用这些信息来发现和确定如何与另一个服务交互。 z 安全性 Web 服务。此服务包含组安全性服务和授权服务。组安全性服务用于管理所有 TFS 用 户和组。授权服务为 TFS 提供一个访问控制系统。 z 链接 Web 服务。此服务使工具能够在其保存的数据元素间建立松散耦合的关系（或“链接” ） 。 例如，一个缺陷工作项和为修订此缺陷而更改过的源代码之间的关系由 TFS 使用一个链接保存。 z 事件处理 Web 服务。此服务使一种工具或服务能够注册事件类型。用户可以通过电子邮件或调 用 Web 服务来提交事件、接收通知。例如，您可以使用一个签入事件来触发连续集成生成。 z 分类 Web 服务。此服务与链接 Web 服务协同工作，使 TFS 项目能够根据预定义的分类法进行 分类。这有助于支持跨工具报告，即便是那些未共享组织数据所用的公共分类法的项目。例如，如 果工作项通常按团队组织，而测试通常按组件组织，那么您可以按团队组织测试，使之可与工作 项一起报告。

数据层 TFS 不支持通过客户端应用程序直接访问数据层中存储的数据。与此不同，所有对数据的请求都必须通 过应用层的 Web 服务进行。TFS 数据层包含以下数据存储，对应于应用层上的数据服务。 z 工作项跟踪。存储所有与工作项相关的数据。 z 版本控制。存储所有与源代码管理相关的数据。 z Team Foundation Build。存储所有与 TFS 团队生成功能相关的信息。 z 报告仓库。存储与所有 TFS 工具和功能相关的信息。报告仓库简化了整合来自多个工具的数据的 报告创建。

部署拓扑 部署 TFS 时，可以使用多拓扑，从单服务器安装到更为复杂的多服务器拓扑均可。无论选择使用了哪 种拓扑，都需要注意一些关键要求。 关键要求 无论选择使用了哪种部署拓扑： z 您必须在同一个域内安装应用层和数据层，但它们可以位于相同或不同服务器节点上。 z 您必须为 TFS 计算机安装 Microsoft Windows Server™ 2003 Service Pack 1 (SP1) 或更新版 本。 z 您必须将所有 TFS 应用层 Web 服务安装到同一个服务器上。 z 您必须将一个 TFS 实例安装到一台单独的物理计算机上。 z 不能在每个物理服务器上安装一个以上的 TFS 实例。 z 不能跨多个数据库服务器分布 TFS 数据库。所有项目都必须位于同一个 Team Foundation 服 务器组中，不可跨组部署。 z 不能使用一个现有 Microsoft SharePoint® Portal Server 基础结构来托管团队项目门户。应考虑使用 一个专用服务器来托管 TFS SharePoint 门户。 z 不应在配置为域控制器的服务器上安装 TFS，因为它不能提供相关支持。

z

对于双服务器部署，必须准备一些域帐户，以便在运行 TFS 服务时使用。例如，您需要创建类 似于 DOMAIN\TFSSERVICE 和 DOMAIN\TFSREPORTS 这样的帐户。

单服务器部署 单服务器部署是最简单的拓扑，适于最多有 400 个用户的开发团队或试验项目。使用这种方法时，将 全部应用层和数据层组件安装在同一个服务器上，并通过同一个域进行访问。 如果需要为性能测试安装测试远程测试机组 (rig) 组件，可以将其安装在服务器节点上，也可以安装在一 个或多个客户端上。图 2.2 展示了单服务器拓扑。 工作站

VSTF 应用服务器 （Windows 2003，ASP.NET，WSS，SQL Server 2005）

Team Foundation 集成服务

Visual Studio 2005 Office （加载项）

命令行

ASP.NET Team Foundation 数据服务 HTTP(s) WSS

团队项目门户站点

操作存储区

其他 SQL Server 2005

数据仓库

图 2.2 单服务器拓扑 双服务器部署 对于 2000 个用户以内的大型开发团队，双服务器部署拓扑非常有用。在这种部署拓扑中，您要将应用 层安装在与数据层分开的单独服务器节点上。 可以在应用层上安装 Team Foundation Build Services，但建议您为大型团队设置一个或多个专用生成服 务器。如果您的项目需要性能测试，那么可以将测试远程测试机组（控制器和代理）部署到额外的服务 器节点。图 2.3 展示了双服务器拓扑。

VSTF 应用服务器 （Windows 2003，ASP.NET，WSS，

工作站

Office （加载项） 命令行

ASP.NET HTTP(s) WSS

Team Foundation 集成服务 Team Foundation 数据服务

MSSQL/TCP

Visual Studio 2005

VSTF 数据库服务器 （Windows 2003， SQL Server 2005）

团队项目门户站点

SQL Server 2005

操作存储区 数据仓库

其他

图 2.3 双服务器拓扑

小结 Team Foundation Server 体系结构由三层构成：客户层、应用层和数据层。 z 客户层包含客户端组件（如 Visual Studio 2005 中的“团队资源管理器” ）、Microsoft Office 集成、 命令行工具等。 z 应用层包含诸如 Team Foundation 版本控制服务、工作项跟踪服务和生成服务之类的组件。 z 数据层包含存储工作项跟踪、版本控制、团队生成和报告仓库所必须数据的数据库。 TFS 支持单服务器和双服务器部署拓扑。在单服务器部署中，应用层和数据层安装在同一台机器上。单 服务器部署对于小型团队或开展试验项目非常有用。在双服务器部署中，应用层和数据层分别安装在单 独的服务器上。双服务器部署对于需要为大量用户进行伸缩的大型团队非常有用。

其他资源 z z z

关于更多 Team Foundation 基础知识，请参见“Team Foundation Server 入门：功能与体系结构简 介” ，地址为：http://msdn2.microsoft.com/en-us/library/ms3 64062(vs. 80).aspx 关于 Team Foundation 的概述，请参见 Microsoft MSDN® Web 站点上的 Team Foundation 产 品文档，地址为：http://msdn2.microsoft.com/enus/library/ms 181 232(vs. 80).aspx 关于 Team Foundation Server 可伸缩性限制的更多信息，请参见“Team Foundation Server 容量 计划”，地址为：http://blogs.msdn.com/bharry/archive/2006/01/04/509314.aspx

第 II 部分 源代码管理 本节内容： ¾ 在源代码管理中设计项目和解决方案的结构 ¾ 在 Team Foundation 源代码管理中设计项目和解决方案的结构 ¾

定义分支和合并策略

¾

在 Visual Studio Team System 中管理源代码管理依赖项

第 3 章 – 在源代码管理中设计项目和解决方案的结构 目标 z z z

合理设计 Microsoft® Visual Studio® Team System 解决方案和项目的结构。 了解何时使用多个解决方案，何时使用单个解决方案。 识别适用于小型、中型和大型团队的结构。

概述 本章介绍了以适于团队开发的方式设计 Visual Studio 解决方案和项目文件结构的各种选项。Visual Studio 使用解决方案 (.sln) 文件将相关的 Visual Studio 项目（.csproj 和 .vbproj）文件组织在一起。确 定如何设置项目和解决方案的结构是一项重要的决策，因为您选择的模式会带来多方面的后果。例如， 它会对您的开发团队程序将解决方案和项目推入/拉出源代码管理的难易程度、用于引用依赖项的机制以 及生成过程产生影响。 如果您在处理一个小型项目，那么可考虑使用单独一个解决方案来包容所有项目文件。如果您在处理 具有大量项目文件的软件开发项目，则应该使用多个解决方案文件，按照整个团队项目中的功能子集 分组相关项目。根据具体方案的不同，您还可能需要使用单个解决方案文件将项目文件组织在一起。

如何使用本章 使用本章来选择设计 Visual Studio 解决方案和项目结构的方法。要从本章中获得最大收益，您应该： z

使用策略列表。使用策略的初始列表：单个解决方案、分区解决方案、多个解决方案，来快速 评估适用于您的方案的最佳方法。

z z

阅读与您的需求最接近的方案部分。阅读介绍如何实现所选选项的部分。 阅读接下来的第 4 章“在 Team Foundation Server 源代码管理中设计项目和解决方案的结构” 。 第 4 章介绍了将代码存储在 Team Foundation Server (TFS) 源代码管理中时，需要牢记的一些重要 考虑事项。 阅读第 6 章“ 在 Visual Studio Team System 中 管 理 源 代 码 管 理 依 赖 项 ”。项目结构影 响跨项目和解决方案管理依赖项时的可用策略。关于如何管理依赖项的更多信息，请阅读第 6 章。

z

z

阅读附带的“如何”文章。阅读以下附带的“如何”文章，获得本章所述各种步骤的详尽演 练。 如何：在 Visual Studio Team Foundation Server 中设计 ASP.NET 应用程序的结构。 如何：在 Visual Studio Team Foundation Server 中设计 Windows 应用程序的结构。 如何：在 Visual Studio Team Foundation Server 中设计源代码管理文件夹的结构。

解决方案和项目结构设计策略 用于设计解决方案和项目文件结构的三种最常用策略如下： z z

单解决方案。如果您在一个小型系统上工作，那么可考虑使用单独一个解决方案来包容所有项目。 分区解决方案。如果您在一个大型系统上工作，使用多个解决方案来将相关项目组织在一起。创建 解决方案，以逻辑方式将一名开发人员很可能将其作为一组修改的项目子集组织在一起，然后创建 一个主解决方案来包含所有项目。仅需要处理特定项目时，这种方法能减少必须从源代码管理中拉

z

取的数据量。 多个解决方案。如果您在一个规模非常大的系统上工作，需要数十个或更多项目，可使用多个解决 方案来处理子系统，但出于依赖项映射和性能方面的原因，不要创建一个包含所有项目的主解决方 案。

总之，您应该： z 除非所得到的解决方案太大，难以载入 Visual Studio，否则应使用单解决方案策略。 z 使用多个解决方案来为应用程序创建子系统的特定视图。 z 使用多个解决方案来减少载入解决方案的时间，为开发人员节省生成时间。 设计项目和解决方案结构时始终牢记以下考虑事项： z 各项目都会在生成时生成程序集。从确定需要创建哪些程序集开始，然后使用此信息来决定需要哪 些项目。再使用这些信息来确定如何将数据库分解到项目中。 z 从最简单的单解决方案结构开始。仅在确实必要时才向结构添加更多复杂性。 z 设计多解决方案结构时：

z

考虑项目依赖项。尽可能将彼此具有依赖关系的项目作为同一解决方案的一部分组织在一起。这 使您能够在解决方案内使用项目引用。通过使用项目引用而不是文件引用，就使 Visual Studio 能 够保持生成配置（调试/发布）同步，并跟踪版本控制来确定何时需要重新生成项目。尽力使跨 解决方案项目引用的数量最小化。 考虑源代码共享。将共享相同源代码的项目放置在同一个解决方案中。 考虑团队结构。设计解决方案的结构时，使团队可以轻松地同时处理一组相关项目。 保持平面项目结构，使您可以轻而易举地将项目组织到解决方案中，而无需更改文件系统或源代 码管理文件夹的结构。

单解决方案 如果您在一个小型系统上工作，那么可考虑使用单独一个 Visual Studio 解决方案来包容所有项目。 这种结构能简化开发，因为在打开解决方案时，所有代码都是可用的。这种战略也简化了引用的设置， 原因在于所有引用都处于该解决方案内的项目之间。您可能还要使用文件引用来引用解决方案外部的 第三方程序集，例如采购到的组件。图 3.1 展示了单解决方案方法。

文件引用 项目引用

外部系统 边界 解决方案 1 项目 A

项目 B 项目 D

项目 C

内部系统 边界

外部 程序集 第三方 组件

项目 E

图 3.1 单 解 决方 案 方法

选择这种结构的主要原因包括： z 可以使生成脚本保持简单。 z 可以轻松在解决方案内的项目间映射依赖项。 如果所有开发人员都使用相同的解决方案、具有相同的项目集，则应使用此结构。对于您希望按子系 统或功能组织项目的大型系统来说，这可能成为一个问题。

分区解决方案 如果您在一个大型系统上工作，那么可以考虑使用多个解决方案，每个解决方案表示应用程序中的一个 子系统。这些解决方案可由开发人员用于 处理系统的较小部分，而无需载入所有项目的代码。设计解决方案的结构时，使具有依赖关系的所有 项目都组织在一起。这使您能够使用项目引用而非文件引用。另外还应考虑创建一个包含所有项目的 主解决方案文件。可以使用它来生成整个应用程序。 注意：与 Visual Studio 早期版本不同，Visual Studio 2005 依赖于 MSBuild。现在有可能创建不包含所 有引用的项目但依然可以无错生成的解决方案结构。只要主解决方案首先生成，从各项目生成了二进制 输出，MSBuild 就能够跟随超出解决方案范围的项目引用，成功生成。这仅在使用项目引用而非文件引 用时有效。通过 Visual Studio 生成命令行、IDE 均可成功生成以这种方式创建的解决方案，但默认不 使用 Team Build。为使用 Team Build 成功生成，使用包含所有项目和依赖项的主解决方案。 图 3.2 展示了分区解决方案方法。

外部系统 边界

项目 A

项目 B 项目 D

项目 C 项目 E

解决方案

项目 H 解决方案

文件引用 项目引用

项目 F

项目 G

外部 程序集 第三方 组件

解决方案

主解决方案

内部系统 边界

图 3.2 分 区 解决 方 案方 法

使用多个解决方案时，应为所有项目采用平面文件结构。典型的示例就是有一个 Microsoft Windows® Forms 项目、一个 ASP.NET 项目、一个 Windows 服务和由其他部分或全部项目共享的一组类库项目 的应用程序。 可以为所有项目使用如下平面结构： z

/Source /WinFormsProject /WebProject /WindowsServiceProject /ClassLibrary1 /ClassLibrary2 /ClassLibrary3 Web.sln Service.sln All.sln

将结构保持为平面结构提供了高度的灵活性和使用解决方案展示项目不同视图的能力。包含解决方案 文件的物理文件夹架构非常难以更改，特别是在您意识到需要重用来自另一个解决方案的类库时。

使用此结构的原因： z 载入和生成应用程序的子解决方案时，性能会得到提升。 z 子解决方案可用于根据开发子团队或代码共享边界创建一组项目的视图。 z 可以使用主解决方案来生成整个应用程序。 z 可以轻松在各子解决方案的项目间映射依赖项。 z 如果解决方案从逻辑上被拆分，那么这种方法可降低整体复杂性。例如，按照技术或功能线拆分解 决方案使新开发人员更容易理解要在哪个解决方案上工作。 不使用此结构的主要原因： z 增加解决方案维护成本。添加新项目时可能要更改多个解决方案文件。

多解决方案 如果您在一个非常大的解决方案上工作，需要数十个项目，那么可能会遇到解决方案可伸缩性限制。此 时，可将应用程序拆分为多个解决方案，但不为整个应用程序创建主解决方案，因为各解决方案内的所有 引用都是项目引用。对各解决方案外部的项目的引用（例如，另一个子解决方案中的第三方库或项目） 是文件引用。这就意味着，不存在任何“主”解决方案。 反之，您必须使用一个了解解决方案所需生成次序的脚本。与多解决方案结构相关联的维护任务之一就 是确保开发人员不会无意中在解决方案间创建循环引用。这种结构需要复杂的生成脚本，以及依赖项关 系的显式映射。在这种结构中，应用程序不可能完全在 Visual Studio 内生成。与此不同，您可以直接 使用 TFS Team Build 或 MSBuild。 图 3.3 展示了多解决方案方法。

外部系统 边界 解决方案 1

项目 A

解决方案 2

项目 B

项目 C

项目 D 内部系统 边界

项目 E

项目 F

解决方案 3

文件引用 项目引用

图 3.3 多 解 决方 案 方法

外部 程序集 第三方 组件

应使用这种结构来避免 Visual Studio IDE 对规模非常大的应用程序造成的性能和可伸缩性约束。 不使用这种结构的原因之一就是它需要使用复杂的生成脚本，以正确的次序生成解决方案，从而跨子 解决方案处理依赖项。

大型项目考虑事项 大型开发团队与小型团队的区别如下： z z z

需要更复杂的分支与合并结构。 很可能要跨解决方案和团队项目管理依赖项。 很可能要维护多个组件和团队的生成。

分区解决方案适用于最庞大的项目，因为它能提供解决方案灵活性，同时又维护一个可用于生成应用程 序的单独解决方案。如果您的应用程序足够大，遇到了解决方案可伸缩性极限问题，则应使用多解决方 案方法。

小结 对于不必将源代码划分成单独的子解决方案的小型项目，可使用单解决方案。 对于开发人员很可能作为一组进行修改的逻辑分组项目子集，可使用分区解决方案，然后创建一个主 解决方案来包含所有项目。 使用多解决方案来创建子系统的具体视图、并减少应用程序的加载和生成时间。 分区解决方案适用于最庞大的项目，因为它能提供解决方案灵活性，同时又维护一个可用于生成应 用程序的单独解决方案。

其他资源 z

关于项目和解决方案结构的更多信息（尽管并非直接适用于 Team Foundation Server），请参见“使 用 Visual Studio .NET 和 Visual SourceSafe 进行团队开发” ，地址为： http://msdn2.microsoft.com/en-us/library/ms998208.aspx

第 4 章 - 在 Team Foundation 源 代 码 管 理 中 设 计 项 目 和解决方案的结构 目标 z z z z z z

设计项目结构，以在 Microsoft® Visual Studio® Team Foundation Server (TFS) 源代码管理中进 行有效的团队开发。 保持服务器端和客户端文件夹结构同步。 为单元测试结构选择一种策略。 创建一个文件夹结构，支持各种分支方案。 了解什么是工作区以及它是如何将本地文件映射到源代码管理的。 理解有哪些文件被添加到源代码管理。

概述 在新建解决方案和项目时，Visual Studio 使用的许多默认文件夹约定都未为团队开发和与 TFS 源 代码管理一起使用而优化。在新建 Visual Studio 项目和解决方案时，不应接受默认设置，而应谨慎 考虑本地和服务器端的文件夹结构。 本章首先解释应如何在开发计算机（客户端）上设计解决方案和项目的结构，然后介绍应如何在 TFS 源 代码管理（服务器端）中设计文件夹的结构。文中提供了用于多种类型的应用程序的示例文件夹结构， 包括 Microsoft Windows® Forms、智能客户端和 Web 应用程序。随后又介绍了如何使用工作区来管理 客户端与服务器文件夹结构间的映射。

如何使用本章 使用本章了解适合各种规模和复杂程度的团队开发项目的示例文件夹结构。要从本章中获得最大收 益，您应该： z

运用服务器端结构建议。运用推荐的服务器端文件夹结构来在 TFS 源代码管理中组织您的项 目源代码。

z 运用客户端结构建议。运用推荐的客户端文件夹结构来在本地开发工作区内组织您的项目 源代码。 z 阅读附带的“如何”文章。这些文章提供了本章所述部分过程的详尽指南： 如何：在 Team Foundation Server 中创建源代码树。 如何：在 Team Foundation Server 中设计 ASP.NET 应用程序的结构。 如何：在 Team Foundation Server 中设计 Windows 应用程序的结构。 如何：在 Team Foundation Server 中设计源代码管理文件夹的结构。

服务器端结构 大多数团队项目都包含一个或多个 Visual Studio 解决方案，每个又包含一个或多个 Visual Studio 项 目。需要进行分支来支持分离的开发路径时，您要使用一个名为 Main 的根级文件夹（在客户端和服务 器上）将 Visual Studio 项目组织在一起。以下是 TFS 源代码管理中的一个示例文件夹结构：

$MyTeamProject1 /Main /Source /MyApp 1 /Source /ClassLibrary1 /MyApp 1 Web /UnitTests /ClassLibrary1Tests /MyApp 1 WebTests /SharedBinaries /SharedSource /Docs /Tests /FunctionalTests /PerformanceTests /SecurityTests /TeamBuildTypes 生成。 /MyApp 1 /BuildType2

Æ可能包含解决方案文件 (.sln) Æ包含 MyApp1.sln 文件 Æ包含所有源代码的文件夹 Æ包含 ClassLibrary1.csproj Æ包含 Default.aspx Æ包含单元测试所用的文件夹 Æ包含测试项目和代码 Æ包含测试项目和代码 Æ共享库，例如：libraries Æ共享源代码 Æ包含产品文档 Æ测试的容器

Æ由 Team Build 自动创建。

Main 是源文件和其他相关工件（如生成输出、设计文档和测试用例）的容器文件夹。一个应用程序文 件夹（如前例中的 MyApp1）包含用于将一组相关 Visual Studio 项目组织在一起的 Visual Studio 解决 方案文件 (.sln)。每个项目文件（.vcproj 或 .vbproj）都包含在 /Main/Source/MyApp1/Source 目录下的 一个专用项目文件夹内。各源项目附属的单元测试位于 UnitTests 文件夹内。可以在 Main 文件夹内 放置额外的 Visual Studio 解决方案文件 (.sln)，以便处理多个不同的项目分组。 Docs 和 Test 文件夹用于容纳与团队项目相关的其他工件，包括产品文档和自动测试。 TeamBuildTypes 文件夹在生成第一个团队生成时自动创建。如果您希望手动签入团队生成类型，可以 手动创建此文件夹，添加您的 Team Build 文件，TFS 会自动为您识别此文件夹。 关于项目分组和解决方案结构的更多信息，请参见“第 3 章 – 在源代码管理中设计项目和解决方案 的结构” 。

存储单元测试 可以将单元测试存储 UnitTests … /MyApp1 /Source /ClassLibrary1 /MyApp1Web /UnitTests /ClassLibrary1 /MyApp1WebTests

文件夹中，该文件夹与 Source 处于同一级别，如下所示。 Æ包含 MyApp1.sln 文件 Æ包含所有源代码的文件夹 Æ包含 ClassLibrary1.csproj Æ包含 Default.aspx Æ包含单元测试所用的文件夹 Æ包含测试项目和代码 Æ包含测试项目和代码

这种方案将单元测试视为“一等公民” 。但这样做的代价是项目级分支兼容性。一种替代性结构如下所示： /MyApp 1 /Source /ClassLibrary1 /ClassLibrary1Tests /MyApp 1 Web /MyApp 1 WebTests 下面列举了每种方法的优缺点：

UnitTest 文件夹与 Source 文件夹处于同等级别 z z z z z

优点：可以在一个位置找到单元测试。 优点：将发布的代码与不发布的代码相分离。 优点：生成过程可以轻松在所有项目上运行所有单元测试。 缺点：开发人员难以仅为其自己的项目运行单元测试。 缺点：分支源代码时，单元测试不会包含在其中。

UnitTest 位于各项目的文件夹中 z z

优点：开发人员可以轻松为单独一个项目运行单元测试。 优点：进行分支操作时，分支的文件夹包含单元测试，因此单元测试可以准确地保留在各分 支的源代码中。

z z

缺点：Source 文件夹中，发布的代码和不发布代码混合在一起。 缺点：在生成时通常很难在所有项目上一次性运行所有单元测试。

存储文档 Documentation 文件夹用于与产品相关的文档。要帮助确定哪些文档要存储在 TFS 源代码管理中，哪些 文档要存储在 Microsoft Windows SharePoint® 团队站点的文档库中，考虑以下几个方面： z

为内部团队文档使用 SharePoint，如用例、方案和需求文档以及设计文档。

z

为发布给客户的产品相关文档使用 TFS 源代码管理。这可能包含安装和部署指南、操作指南和帮 助文件。

大多数文档都是二进制文件，因此应考虑使用互斥锁来避免手动合并。这样，一个文件正被使用时您会 得到通知，也就能帮助避免不得不去执行手动合并。 在使用 SharePoint 时应倍加谨慎，因为需要严格的文档版本管理。与 TFS 源代码管理相比，在 SharePoint 中更容易覆盖更改。默认情况下，在上载文件时，SharePoint 的“覆盖现有文件”选项处于 选中状态。

客户端结构 开发工作站上的本地文件夹结构与服务器文件夹结构相同。可将源代码文件很好地组织在工作站中： 将来自所有团队项目的全部源代码放在一个根文件夹下，例如 C:\DevProjects。同时为每个团队项目 创建一个子文件夹，如下例所示： C:\DevProjects \MyTeamProject1 \MyTeamProject2

Æ根容器文件夹，包含所有团队项目 ÆTeamProject1 的容器文件夹 ÆTeamProject2 的容器文件夹

在各团队项目文件夹下，使用源代码管理服务器所用应用程序文件夹结构的一份副本，如下例所示： \MyTeamProject1 ÆTeamProject1 的容器文件夹 \Main Æ包含跨项目的 .sln 文件 \Source \MyApp 1 Æ包含 MyApp1.sln \Source \ClassLibrary1 Æ包含 ClassLibrary1.csproj \MyApp1Web Æ包含 Default.aspx \UnitTests Æ包含单元测试项目和源代码 \ClassLibrary1Tests \MyWinApp1Tests \SharedBinaries Æ共享二进制文件，例如：libraries \SharedSource Æ共享的源代码 \Docs Æ包含产品文档 \Tests Æ测试的容器 \FunctionalTests \PerformanceTests 注意：如果您创建了从应用程序根到本地计算机的工作区映射，客户端结构会自动反映服务器端结构。

然而，在规模极大的项目中，这可能会导致工作区加载时间变长。要为规模极大的项目进行优化，在 根下创建工作区映射，仅检索开发所需文件。

分支文件夹 为了通过分支支持开发分隔，创建与 Main 文件夹同级的其他文件夹。可以在 Main 文件夹内放置额 外的 Visual Studio 解决方案文件 (.sln)，以使开发人员能够处理多个不同的项目分组。从 Main 源文件 夹创建的分支可用于支持产品发布或开发平行流的连续维护。 在以下的示例结构中， 除了 Main 根文件夹之外，还使用了一个 Development 文件夹（分支自 Main） 来提供功能分隔或团队分隔。Releases 文件夹是发布分支（同样分支自 Main）为需要连续维护的已 发布生成和当前的发布推行提供分隔。 $MyTeamProject1 /Development /FeatureBranch1 /Source

/MyApp

/FeatureBranch2 /Source

/MyApp /Main /Source /Releases /Release1 – Maintenance /Source /MyApp /Release2 – Maintenance /Source /MyApp /Release3 – Current release lockdown /Source /MyApp 注意：除非必要，否则不要进行分支。如有必要，可以为一个发布加标签，稍后再进行分支。 关于项目分组和解决方案结构的更多信息，请参见“第 3 章 – 在源代码管理中设计项目和解决方 案的结构”。 关于分支方案和相关文件夹结构的更多信息，请参见“第 5 章 – 定义分支和合并策略”。

工作区详解 TFS 工作区就是 TFS 源代码管理中文件与文件夹的客户端副本。工作区映射将源代码管理的文件夹映 射为本地文件系统目录。在本地计算机的工作区内对文件进行更改时，本地更改——也称为挂起的更改 ——隔离在您的工作区内，直至将其作为原子单元签入服务器。成批签入的一组更改称为变更集。 单独一个工作区可以包含对多个团队项目的引用。还可使用多个工作区来分隔文件或版本，仅供您自 己使用。工作区按计算机、按用户账户的不同而不同。因此，对于您所使用的每一台计算机，都可能 有不同的工作区定义。此外，作为一名用户，您可以在一台计算机上有多个工作区。 注意：通过使用一个工作区，仅能映射本地文件系统上的各物理位置。但可以使用不同的工作区，将各 server 目录映射为完全不同的本地目录。

新建工作区映射

由于映射是递归的，在新建工作区映射以及在该工作区的根执行“获取最新版本”操作时，整个本地 文件夹结构将自动创建。新创建的本地文件夹结构与服务器结构匹配。 新建工作区映射时，始终牢记以下建议： z z

首次将解决方案添加到源代码管理之前，项目所有者必须确保本地使用了正确的文件夹结构。 首次为一个团队项目建立工作区映射并执行“获取最新”操作时，应确保将根团队项目文件夹映射 为恰当的本地文件夹，例如 C:\DevProjects\TeamProject1。

工作区映射存储在哪里？ 工作区信息同时在客户端和服务器维护。在客户端，工作区信息位于 VersionControl.config 文件中，该 文件位于以下文件夹内： \Documents and Settings\[user]\Local Settings\Application Data\Microsoft\Team Foundation\1 .0\Cache.

VersionControl.config 文件将工作区的名称映射到您的计算机的本地目录。它并未包含独立源代码管理 文件夹和您的本地目录间的映射。.服务器上保存的信息处于 TfsVersionControl 数据库内的几个表中 （包括 tbl_Workspace 和 tbl_workingfolder）。

掩蔽 希望防止源代码管理的某个部分被检索时，可以将掩蔽作为性能优化措施。下面是使用掩蔽的典型方案： z z

希望在本地生成项目，而且生成并不需要某个文件夹，例如一个文档文件夹。 您是大型团队项目的以部分，而且只希望检索部分项目。

无论是上述哪种情况，都可以掩蔽文件夹，阻止客户端检索这些文件夹。要在客户端掩蔽文件夹，可以 编辑工作区并将工作文件夹的状态从活动更改为掩蔽。 在进行掩蔽时，始终牢记以下考虑事项： z z

不要掩蔽单独的文件。这很可能会在此后导致项目中出现维护问题。 对于大型项目，映射根文件夹并掩蔽子文件夹，不要为项目创建多个工作区。

应对哪些文件进行版本控制？ 下面的列表识别了应添加到源代码管理的关键文件类型。应在单击“将解决方案添加到源代码管理” 时将这些文件类型添加到其中。 z z z z

解决方案文件 (*.sln)。解决访问文件包含成员项目的列表、依赖项信息、生成配置细节和源代 码管理供应者细节。 项目文件（*.csproj 或 *.vbproj）。项目文件包含程序集生成设置、引用程序集（按名称和路 径）和文件清单。 Visual Studio 源代码管理项目元数据 (*.vspscc)。这些文件维护项目绑定、排除列表、源代码管 理供应者名称和其他源代码管理元数据。 应用程序配置文件 (*.config)。可扩展标记语言 (XML) 配置文件包含项目和应用程序的具体细节， 用于控制应用程序的运行时行为。Web 应用程序使用名为 Web.config 的文件。非 Web 应用程序 使用名为 App.config 的文件。

注意：在运行时，Visual Studio 生成系统将 App.config 复制到项目的 Bin 文件夹中，将其重命名 为 <YourAppName>.exe.config。对于非 Web 应用程序，则不会为新项目自动添加配置文件。如果 需要，可以手动添加。确保将其命名为 App.config 并放置在项目文件夹内。 z z

源文件（*.aspx、*.asmx、*.cs、*.vb 等）这是源代码文件，具体取决于应用程序的类型和语言。 二进制依赖项 (*.dll)。如果您的项目依赖于二进制依赖项，例如第三方动态链接库 (DLL)，还应在 源代码管理中将其添加到项目中。关于依赖项管理的更多信息，请参见“第 6 章 – 在 Visual Studio Team System 中管理源代码管理依赖项” 。

不应对哪些文件进行源代码管理？ 以下文件特定于各开发人员，因此不应添加到版本控制中： z z z

z

解决方案用户选项文件 (*.suo)。这些文件中包含一位开发人员对 Visual Studio IDE 进行的个性 化自定义操作。 项目用户选项文件（*.csproj.user 或 *.vbproj.user）。这些文件中包含特定于开发人员的项 目选项和可选引用路径，Visual Studio 使用它来定位引用的程序集。 WebInfo 文件（*.csproj.webinfo 或 *.vbproj.webinfo） 。此文件跟踪项目的虚拟根位置。此文件不 会添加到源代码管理中，以允许各开发人员为自己的项目工作副本指定不同的虚拟根。尽管这种功 能是存在的，但建议所有团队成员在开发 Web 应用程序时都使用一个一致（本地）的虚拟根位置。 生成输出。包括程序集 DLL、互操作程序集 DLL 和可执行文件 (EXE)。 （但请注意，有些程序集 不会作为生成过程的一部分生成，比如第三方二进制文件，这些程序集应纳入版本控制，如上文所 述。 ）

小结 为实现有效的团队开发在 TFS 源代码管理中设计项目的结构。使用一个名为 Main 的根级文件夹将您 的 Visual Studio 项目组织在一起。Main 文件夹应包含子文件夹来存储各项目资产，例如源代码、测试、 文档和团队生成类型。 为内部的团队文档使用 SharePoint，如用例和设计文档。为计划发布给客户的产品相关文档使用 TFS 源 代码管理。这可能包含安装和部署指南、操作指南和帮助文件。 保持服务器端和客户端的文件夹结构同步，以便减少因文件夹组织差异导致的混乱。要为

规模非常大的项目优化方法，可在根下创建工作区映射，确保仅检索开发所需的文件。

其他资源 z

关于 Team Foundation 源代码管理的更多信息，请参见“在 Team Foundation 中使用源 代码管理”，地址为：http://msdn2.microsoft.com/en- us/library/ms 3 64074( VS. 80).aspx

z

关于创建工作区的更多信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms 1813 84(VS. 80).aspx

第 5 章 – 定义分支和合并策略 目标 z z z z

了解何时应进行分支、何时不应进行分支。 为您的项目选择一种分支和合并策略。 描述普通的分支策略需如何调整才能支持非常大型的团队。 为不同的分支方案确定恰当的文件夹结构。

概述 本章介绍了适用于一些常见方案的分支和合并策略。通常情况下，您需要进行分支来支持发布或平行开 发。 对于许多简单的方案，并不需要分支，对生成进行标记足矣。例如，通过使用标签，可以在将来的任意 时刻重新创建一个生成，或者查明创建特定生成时使用的是一个源文件的哪个版本。如果需要为平行团 队进行隔离，无论是为了处理分离但有重叠的功能，还是为了支持发布，都应考虑分支。

如何使用本章 使用这一章来了解何时应进行分支、何时不应进行分支。如果您确定，分支适合您的情况，可以使用 这一章来了解如何有效地进行分支和合并、 如果希望获得分支和合并的概览，可以从头至尾阅读本章，了解不同的分支策略和适用分支的不同方 案。如果您对某个具体方案感兴趣，可直接跳到相关小节。要从本章中获得最大收益，您应该： z

使用方案列表。使用方案列表来定位最接近您的情况的方案。阅读建议来创建适合您的需求的 分支文件夹结构。

z

使用附带的指导原则。参考本指南中“源代码管理指南”内的分支与合并指导原则，获得分支和 合并指导原则的汇总。

分支与合并的方案 下面是一些需要创建分支、执行合并的方案示例。 z

如果经常存在拆分生成的问题，就应该创建一个开发分支来分隔平行的开发工作。

z

如果有一些功能引起了稳定性问题，或者有团队导致了团队间的稳定性问题，则应在源代码管理 的一个开发容器文件夹下创建单独的功能或团队分支。

除非分支对于开发团队是必要的，否则不要进行分支。分支会引入额外的源代码树维护及合并任务。 大多数开发团队，例如生成业务线应用程序的团队，都在较短的发布周期内工作，并不需要分支。而 在较长的发布周期内工作的开发团队，例如独立软件供应商 (ISV)，它们生成打包的应用程序，很可能 需要将分支作为开发过程的一部分。 如果您有一个开发流，或者正在进行增量、连续的发布，那么可能不需要创建分支，除非经常遇到使 整个开发工作不稳定的中断性变更。

实践中的常见方案

下面列举了最常见的分支方案： z z

z

z

z

方案 1 – 无分支。您的团队仅通过主源代码树工作。在这种情况下，不必创建分支，也不需要分隔。 这种方案通常适用于小型或中型团队，这些团队不需要为团队或功能分隔，也不需要为发布而分隔。 方案 2 – 为发布分支。您的团队创建分支来支持进行中的发布。这是第二种最常见的情况，您需 要创建分支来使发布稳定。在这种情况下，您的团队在发布之前创建分支，使发布稳定，随后在 软件发布后将发布分支的更改合并回主源代码树。 方案 3 – 为维护分支。您的团队创建分支来维护旧生成。在这种情况下，您为维护工作创建一个分 支，避免使当前生产生成出现不稳定的情况。可能会也可能不会将维护分支的更改合并回主树。例 如，您可能正致力于面向一部分客户的快速修订程序，而不希望将其包含在主生成中。 方案 4 – 为功能分支。您的团队根据功能创建分支。在这种情况下，创建一个开发分支，在开发 分支中完成工作，然后将其合并回主源代码树。您可以创建多个单独的分支，用于平行完成的特定 功能。 方案 5 – 为团队分支。为隔离子团队而进行分支，使子团队能够在不受中断性变更影响的前提 下工作，或者可以朝着不同的里程碑平行工作。

您可能会遇到上述一种或几种情况。将这些方案作为参考，看看哪些指导原则适合您，哪些不适合。

示例文件夹及其用途 以下是一些示例文件夹，为分支和合并方案设计源代码树结构时，您可能在 Microsoft® Visual Studio® Team Foundation Server (TFS) 源代码管理中创建这些文件夹。 z z z

Development 分支自 Main，用于分隔活动的开发工作。开发分支可能是临时的，目的是在不影响 Main 的前提下开发有风险的变更。 Main 包含主源代码树。来自其他分支的变更在这里整合。 Releases 包含已发布但现需为客户维护的分支。这提供了与开发分支中出现的活动开发工作的分 隔。它还包含一个当前发布分支，也是分支自 Main，其中包含当前发布前推行的版本。在此分支 中工作来准备发布软件，而其他人员仍然可以继续在 Development 分支中开发新功能。

下面几个小结展示了分支在前述各方案中的用法，附带具体示例。

方案 1 – 无分支 此方案通常适用于小型团队，对于这种团队来说，分隔开发并非关注点。通过标记生成，就能够检索对 应于一个具体生成的源代码。没有必要引入分支的复杂性，因为您可以直接通过 Main 文件夹工作。 下面的视图展示了无分支方案： My Team Project Main Source

方案 2 – 为发布分支 在这种方案中，您创建一个分支来使发布更稳定，然后在软件发布后将发布分支合并回主源代码树。下 面的视图展示了为发布分支的方案： My Team Project MainÆ

主集成分支 Source

Releases

Release 1Æ Source

发布分支

方案 3 – 为维护分支 在这种方案中，您为维护工作创建一个分支，避免使当前生产生成出现不稳定的情况。下面的视图展示 了维护分支：这与发布分支非常相似，但此时分支会维护一段时间，以支持发布： My Team Project Main Source Releases Release 1 Source 其他资产文件夹 Release 2 Source 其他资产文件夹

Æ主集成分支 Æ维护分支容器 Æ维护分支

Æ维护分支

方案 4 – 为功能分支 在这种情况下，创建一个开发分支，在开发分支中完成工作，然后将其合并回主源代码树。您根据产品 功能组织开发分支。下面的物理视图展示了为功能开发而进行的分支： My Team Project Feature A Source Feature B Source Feature C Source Main Source

Æ独立的开发分支容器 Æ功能分支 Æ功能分 Æ功能分支 Æ主 集成分支

方案 5 – 为团队分支 这种方案类似与之前按功能分支的方案，差别是根据子团队而非产品功能组织开发分支。在团队和功能 直接可能存在一对一的关系，但在某些情况下一个团队可能要开发多个功能。下面的物理视图展示了为 子团队开发而进行的分支： My Team Project Development Team 1 Feature A Source Feature B Source Team 2 Feature A Source Feature B Source Main Source

Æ独立的开发分支容器 Æ团队分支 Æ 用于开发的独立分支 Æ 用于开发的独立分支 Æ团队分支 Æ用于开发的独立分支 Æ用于开发的独立分支 Æ主集成分支

逻辑结构 逻辑结构由各分支的父/子关系构成。这可能与您在“源代码资源管理器”中看到的物理结构有所不同。 例如，在前面的物理结构中，Development 和 Main 在同一级别出现，而 Development 实际上是 Main 的子级。 图 5.1 展示了逻辑关系示例，还展示了分支和合并流是如何贯穿整个结构的。

维护

集成

开发

图 5.1 展示分支和合并流的逻辑关系

发布方案 图 5.2 展示了为发布进行分支时的典型时间线：

图 5.2 为发布进行的分支时间线 事件的顺序如下： 1.

2.

3.

4.

5.

一旦发布准备好推行，Release 1 分支就会从 Main 创建。 定期合并到 Main 中，这确保了来自发布的 bug 修订转入主集成分支。 发布生成在 RTM 分支中标记并合并回 Main。 服务包 SP1 已经发布。生成被标记，更改并合并入 Main。 Release 1 分支继续存在，支持 SP1，并为未来的服务包提供支持。

此过程为未来发布重复执行。 注意：发布分支的成功使用要求您确定出在实现前应为哪些分支应用修订。如果将一个修订作为补 丁程序或服务包发布，应首先在恰当的 Release 分支上作出更改，然后将其合并到 Main 中，确保 它应用于未来发布。

隔离的开发方案 图 5.3 展示了为开隔离进行分支时的典型时间线。

图 5.3 为开发隔离进行的分支时间线

事件的顺序如下： 1. 为 Feature A 的隔离开发创建一个功能分支。 2. 为 Feature B 的隔离开发创建一个功能分支 3. 在功能里程碑完成时，各团队将其更改合并到 Main，使之可集成到主生成中，并可由其他团队获 取。 4. 以定期的时间表为依据，各团队合并来自 Main 的最新更改，以便与其他团队的工作保持同步， 并减少每次合并的冲突数量。 5. 功能完成时，更改全部合并回 Main，功能分支被删除。

分支考虑事项 进行分支时，应考虑以下事项： z

z z z

z z z z

除非开发团队需要同时在相同的文件集上工作，否则不要分支。如果无法确定，可以标记生成， 此后再从该生成创建分支。合并分支可能非常耗时、非常负载，特别是在分支间存在重大更改时 更是如此。 设计分支树结构时应考虑合并，应使您只需沿层次结构合并（在分支树中上下移动） ，而不需要 横跨层次结构。跨层次结构的分支要求您使用 baseless 合并，需要手动解决更多冲突。 分支层次结构基于分支父级和分支子级，可能与磁盘中源代码的物理结构有所不同。计划合并时， 应始终牢记逻辑分支结构，而不是磁盘上的物理结构。 分支深度不要过大。由于需要花时间来执行每次合并并解决冲突，因此过深的分支结构可能就 意味着子分支中的更改要花很长时间才能传播到主分支。这可能会对项目进度造成负面影响， 并增加修订 bug 的时间。 在高级别分支，包括配置和源文件。 逐渐发展您的分支结构。 合并要求一名或多名开发人员执行合并并解决冲突。应全面测试合并后的源代码，可能毁掉生成 的糟糕合并决策并不罕见。 跨分支层次结构进行合并尤为困难，需要您手动处理许多在其他合并方式中会自动处理的冲 突。

是否创建分支的决策可归结为实施合并冲突的成本是否高于在分支间合并冲突的总成本。

大型项目考虑事项 具有较长开发周期的大型开发团队与小型团队的区别如下： z z z

需要更复杂的分支与合并结构。 很可能要跨解决方案和团队项目管理依赖项。 很可能要维护多个组件和团队的生成。

大型团队很可能要同时按团队和功能分支，也有可能有一个或多个专门用于集成外部依赖项的分支。分 支结构更深，开发分支中出现更改与该更改合并入主集成分支间的延时也就更长。出于这方面的原因， 应该在创建分支时谨慎考虑合并策略。 例如，在决定选择预定合并还是事件驱动型合并时，考虑以下几个方面： z z

反向集成通常是预定的，例如从开发分支到主集成分支的合并。 正向集成（如从主集成分支到开发分支的合并）通常是基于事件的，例如一个功能里程碑完成。此

事件在负责开发分支的团队认为自己已经准备好合并来自其父分支的更改时发生。 根据您希望产生生成的频率合理地设置分支/合并策略。较深的分支结构会导致从子分支到主集成分 支的合并时间更长。这种情况给您的开发团队导致问题的征兆包括： z z z

如果修订传播到主集成分支的时间过长，那么就应该拆分生成。 由于功能传播到主分支的时间过长，导致里程碑丢失。 花费了大量时间在各分支间合并更改。

如果这对您的团队造成困扰，可以考虑减少分支结构的深度。 下面是一个复杂分支结构的示例： z

My Team Project o Development – 分隔活动的开发分支的容器 Feature A – 用于开发的独立分支 z Source Feature B – 用于开发的独立分支 z Source o Main – 主集成生成分支所有变化都汇聚于此。 Source 其他资产文件夹 o Releases – 当前 发布和维护分支的容器 Release 2– 活动的维护分支 z Source z 其他资产文件夹 Release 3– 活动的维护分支 z Source z 其他资产文件夹 Release 4 – 包含当前推行到发布的代码的分支 z Source z 其他资产文件夹 Safe Keeping Release 1 – 安全保护中的旧发布 z Source z 其他资产文件夹

此结构包括： z z z z z

用于使多个团队隔离工作的功能分支。 一个主分支，汇集所有团队作出的更改和来自发布分支的 bug 修订。 一个用于推行当前发布的发布分支。 一个得到积极维护和支持的旧发布的维护分支。 不再维护的旧发布的保护分支。

小结

通常，分支创建用于推行一个发布、维护之前的发布或执行分隔的平行开发。除非有充足的理由，否则 就不应进行分支。 创建分支时，应按照这种方式设计分支树的逻辑结构：只需沿层次结构合并（在分支树中上下移动） ， 而不需要横跨层次结构。跨层次结构进行合并非常耗时，而且易于出错。 对于大型团队来说，分支结构更深，因此应做好准备，一个开发分支中发生更改与这些更改合并回主集成 分支之间会有较长的延时。

其他资源 z z z z

关于分支与合并的简介，请参见“分支与合并入门” ，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 关于分支的更多信息，请参见“如何：分支文件和文件夹” ，地址为： http://msdn2.microsoft.com/en-us/library/ms 181 425(VS. 80).aspx 关于合并的更多信息，请参见“如何：合并文件和文件夹” ，地址为： http://msdn2.microsoft.com/en-us/library/ms 181 428(VS. 80).aspx 关于如何在 Visual Studio 2005 中进行分支与合并的更多信息，请参见“对 Team Foundation 源代 码管理进行分支和合并” ，地址为：http://msdn2.microsoft.com/en-us/library/ms 181423 (VS. 80).aspx

第 6 章 – 在 Visual Studio Team System 中管理源代码管理依赖项 目标 z z z z z z

在 Microsoft® Visual Studio Team System 中管理源代码管理依赖项。 在同一个团队项目中引用来自不同解决方案的项目和程序集。 引用来自其他团队项目的项目和程序集。 引用第三方程序集。 在团队环境中管理 Web 服务引用。 在团队环境中管理数据库引用。

概述 这一章解释了应如何处理 Visual Studio 解决方案内和跨 Visual Studio 解决方案的源代码管理依赖项。 为了降低生成的不稳定性和连续的源代码管理维护成本，有必要找到一种在团队环境中管理依赖项的一 致方法。 依赖项包括其他项目、外部程序集、Web 服务和数据库。依赖项不可避免地会逐渐发生更改，因而也 会影响到生成过程和应用程序的生成次序。出色的依赖项管理方法会改进集成过程，同时使生成尽 可能地无缝。

如何使用本章 使用本章来了解在团队环境中管理依赖项的相关内容。可以从头至尾阅读本章，也可以阅读符合您的 具体依赖项管理需求的小节。使用“方案和解决方案”一节来理解团队环境中的一般依赖项管理方案。 本节总领以下几节，下面几节将详细介绍各种依赖项方案。 使用“引用项目”一节学习如何管理当前团队项目内外的其他项目中的依赖项。 使用“引用第三方程序集”一节学习如何管理 没有源代码的第三方程序集中的依赖项。 使用“引用 Web 服务”一节学习如何 在团队环境中引用共享的 Web 服务。 使用“引用数据库”一节学习如何在团队环境中连接到共享数据库。

方案和解决方案 下面是管理依赖项时的几种常见方案： 1.

2.

您希望引用同一解决方案中另一个项目生成的程序集。 您希望引用另一个解决方案中另一个项目生成的程序集。

3.

4.

您希望引用另外一个团队项目中包含的程序集。 您希望引用一个第三方程序集。

引用同一解决方案中另一个项目生成的程序集 如 果 需 要 引 用 同 一 Visual Studio 解决方案中的另一个程序集，可使用 Visual Studio 项目引 用。通过使用项目引用，就使 Visual Studio 能够自动为您完成一些工作，例如保持生成配置（调试/ 发布）同步，在程序集版本更改时跟踪必要的组件版本控制和重新生成。

引用另一个解决方案中的项目生成的程序集 如 果 需 要 引 用 另 一 个 Visual Studio 解决方案中的某个项目生成的程序集，有两个选择： 使用文件引用指向二进制程序集。 将这个 Visual Studio 项目（项目和源文件）添加到您的解决方案中，然后使用项目引用。 文件引用比项目引用更易出错，不符合生成配置，也不会被 Visual Studio 生成依赖项跟踪。因此， 如果您引用的程序集发生了更改，Visual Studio 生成系统无法自动了解需要重新生成。 除此之外，您可以将外部项目分支到您的解决方案中，生成二进制文件，然后使用一个项目引用。 引用将变得更加健壮，但需要定期合并多个源代码分支，以获取更改。

引用另一个团队项目中的程序集 如果跨团队项目共享源代码或二进制文件，那么有两个选择： 分支。通过这种方法，即可将其他团队项目中的源代码分支到您的当前解决方案中。这还会 在服务器端创建一个配置，将来自共享位置和您的项目的源代码统一。 工作区映射。通过这种方法，即可其他团队项目中的源代码映射到开发计算机上的工作区中。 这会在客户端创建一个配置，将来自其他团队项目的源代码和您的项目的源代码统一。 分支是首选方法，因为它在源代码管理服务器上存储依赖项关系。工作区映射是仅适用于客户端的 方法，也就是说，您和所有开发人员都必须在自己的计算机和生成服务器上创建映射，这样才能成 功生成应用程序。 分支会带来额外的合并开销，但使您能够作出决策，更为显式地获取更新的二进制文件或源代码。

引用第三方程序集 这种方案与跨团队项目引用非常类似，差别在于您仅仅共享二进制文件，而不是源代码。分支和工 作区间的选择非常类似，一个需要注意的地方就是开销很可能会降低，因为第三方程序集变动的可 能性不大。

引用项目 如 果 有 一 个 Visual Studio 项目，例如一个包含由多个团队项目使用的共享库代码的团队项目，那 么可以在拥有团队的项目的项目内进行管理，也可以创建一个单独的团队项目，专门用于共享的项目。 如 果 选 择 了 后 一 种 方 法 ， 使 用 一 个 公 共 共 享 项 目 ， Microsoft Visual Studio Team Foundation Server (TFS) 源代码管理内的文件夹结构应类似于图 6.1。

由其他多个团队项目引 用的共享项目

需要从 Common 团队项目 中引用 CommonProj

需要从 Common 团队项目 中引用 CommonProj

图 6.1 使用了一个公共、共享的项目文件夹结构

要从您自己的团队项目中使用公共的共享项目，有两种选择：

分支 工作区映射

分支 分支是大多数共享源代码的方案的首选方法。它使您能够将共享的源代码拉入您的项目，并将其签 入团队项目的源代码管理。在这一方案中，您将公共共享位置的共享源代码分支到您的团队项目中。 这还会在服务器端创建一个配置，将来自共享位置和您的项目的源代码统一。 共享源代码的更改会作为分支间合并过程的一部分被获取。这会作出决策，更为显式地获取共享源代码 中的更改，而且更易于测试，但也会增加一定的开销。除此之外，此过程能够更轻松地利用 Team Build， 因为映射已经在服务器端完成，不需要在生成服务器上复制任何客户端映射。 例如，有两个团队项目，名称分别为 $TeamProject1 和 $Common，Common 是共享的项目源代码， 您要创建一个从共享位置到引用它的项目的分支。TFS 文件夹结构应类似于图 6.2。

从 Common 分支

从 Common 分支

图 6.2 使用分支

工作区映射应类似于以下形式： 源代码管理文件夹

本地文件夹

$/MyTeamProject1/Main/Source/ C :\MyTeamProject\Main\Source 客户端工作区文件夹结构应类似于图 6.3。

从 Common 分支

图 6.3 客户端工作区映射

工作区映射 如果您希望开发人员能够立即获取任何代码更改，而不会招致任何分支和合 并开销，可以将公共项目中的共享源代码映射到开发计算机的工作区中。这 还会在客户端创建一个配置，将来自共享位置和您的项目的源代码统一。 这种方法的优势是每次您将最新源代码检索到您的工作区时，共享的项目更改都会被获取。然而， 这使 Team Build 的用法更加复杂，因为工作区映射是由客户端构建的。 例如，我有两个团队项目，名称分别是 $MyTeamProject 和 $Common，Common 是共享的项目源代码， 为了引用共享位置的代码，这些项目在客户端的硬盘上共享一个公共路径。客户端工作区文件夹结 构应类似于图 6.4。

统一配置。工作区映射用于将 Common 项目映射到客户端源代码树中

图 6.4 使用工作区映射

工作区映射应类似于以下形式： 源代码文件夹

本地文件夹

$/MyTeamProject2/Main/Source/

C:\DevProjects\MyTeamProject2\Main\Source\ C:\DevProjects\MyTeamProject2\Main\Source\ Common

$/Common

更 多 相 关 信 息 ， 请 参 见 “ 在 团 队 生 成 中 处 理 多 个 团 队 项 目 ”， 地 址 为 ： http://blogs.msdn.com/manishagarwal/archive/2005/1 2/22/506635 .aspx

引用第三方程序集 如果您无法使用项目引用，又需要引用当前解决方案集以外的程序集，例如 一个第三方库，而且不希望或无法创建一个从原项目到您的项目的分支，则 必须设置文件引用。 管理共享库与管理共享项目源代码非常类似，您必须决定在何处存储二进制文件，以及您希望团队 如何访问这些二进制文件。如 果 有 供 多 个 团 队 项 目 使 用 的 二 进 制 文 件 ，那 么 可 以 在 拥 有 团 队 的 团 队 项 目 内 管 理 二 进 制 文 件 ，也 可 以 专 为 共 享 二 进 制 文 件 创 建 一 个团队项目。 对于使用共享二进制文件的团队，与可用于引用项目的两个相同选项可用于二进制文件。 z

分支

z

工作区映射

分支 在这一方案中，您将公共共享位置的二进制文件分支到您的团队项目中。这还会在服务器端创建一 个配置，将来自共享位置的二进制文件和您的项目统一。 差别在于对二进制文件作出的任何更改（如获取新版本）都会作为分支间合并过程的一部分获取。 这会作出决策，更为显式地获取更改后的共享二进制文件。 例如，有两个团队项目，名称分别为 $TeamProject1 和 $Common，Common 包含共享的二进制文 件，您要创建一个从共享位置到引用它的项目的分支。TFS 文件夹结构应类似于图 6.5。

从 Common 分支

图 6.5 从 Common 分支

工作区映射应类似于以下形式： 源代码管理文件夹

本地文件夹

$MyTeamProject1

c:\TestProject\Client

客户端工作区文件夹结构应类似于图 6.6。

图 6.6 客户端工作区文件夹结构

工作区映射 在使用共享二进制库的团队项目中，将来自共享位置的二进制文件引用到开发计算机的工作区中。 这还会在客户端创建一个配置，将来自共享位置的二进制和您的项目统一。 这种方法的优势是每次您将最新源代码检索到您的工作区时，共享的二进制文件更改都会被获取。 例如，有两个团队文件，名称分别为 $TeamProject1 和 $Common，TeamProject1 引用 Common 中 的二进制文件，随后客户端工作区文件夹结构应如图 6.7 所示。

包含公共 共享库

图 6.7 存储公共的共享库

工作区映射应类似于以下形式： 源代码管理文件夹 $/MyTeamProject2/Main/ $/Common/Main/Bin

本地文件夹 C:\DevProjects\MyTeamProject2\Main\ C:\DevProjects\MyTeamProject2\Main\Source\CommonBin

更多相关信息，请参见“在团队生成中处理多个团队项目”，地址为： http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx

引用项目和程序集的指导原则 可以通过以下两种方式的任何一种来设置文件引用： z

要引用一个 .NET Framework 程序集，可以从“添加引用”对话框的 .NET 选项卡中显示的列 表内选择相应程序集。

z

可以在“添加引用”对话框中使用“浏览”按钮。

像 System.XML.dll 这样的程序集位于全局程序集缓存 (GAC) 中。但无法直接引用 GAC 内的程序 集。与此不同，在“添加引用”对话框的 .NET 选项卡中选择一个程序集时，实际上引用的是该程 序集的一个副本，位于 %windir%\Microsoft.NET\Framework\<version>\ 文件夹内。 项目引用优于文件引用。管理程序集引用时应始终牢记以下指导原则： z

尽可能使用项目引用。

z z

只在必要的情况下使用文件引用。 为项目和文件引用使用 Copy Local = True。

有关更多信息，请参见本指南中的“源代码管理指导原则”。 自动依赖项跟踪 每次生成本地项目时，生成系统都会将所引用的程序集文件的日期和时间与开发工作站上的工作副 本相比较。如果引用的程序集更新，则将新版本复制到本地文件夹。这种方法的优点之一在于，一 名开发人员创建的项目引用不会锁定服务器上的程序集动态链接库 (DLL)，也不会以任何方式干扰 生成过程。

引用 Web 服务 在较为简单的系统中，系统的所有项目都包含在同一个团队项目中，所有开发人员最终得到的都是 全部 Web 服务的本地工作副本，因为它们是由团队项目内的 Visual Studio 项目定义的。初次从源 代码管理中打开一个解决方案时，所有项目（包括任何 Web 服务）都在本地安装。类似地，如果 一个 Web 服务被其他开发人员添加到解决方案中，您也会在下一次从源代码管理中刷新解决方案 时安装这个 Web 服务。在这种方案中，不需要在团队环境内的中心 Web 服务器上发布 Web 服务。 对于较大的系统，可以通过 Internet Information Server (IIS) 在集中访问的 Web 服务器上发布 Web 服务，并非所有开发人员都需要在本地安装 Web 服务。反之，开发人员可以从其客户端项目访问 Web 服务，但您需要按照下文的介绍合理引用 Web 服务。 有关更多信息，请参见本指南的中的“源代码管理指南”和“源代码管理实践”。

在引用 Web 服务时使用动态 URL 如果希望调用 Web 服务，必须首先为项目添加一个 Web 引用。这将生成一个代理类，可通过它 与 Web 服务交互。代理代码最初包含一个 Web 服务的静态统一资源定位符 (URL)，例如 http://localhost or http://SomeWebServer。

重点：对于在您的计算机上执行的当前解决方案内的 Web 服务，应该总是使用 http://localhost 而 非 http://MyComputerName，以确保引用在所有计算机上都有效。 代理中内嵌的静态 URL 通常不是生产或测试环境所需的 URL。 根据应用程序的不同，从开发、测试到生产各有不同。要解决此问题，您有三个选择： z

创建该代理类的实例时，可通过编程方式设置 Web 服务 URL。

z

还有一种更灵活的方法，可以避免在代理中硬编码 URL，也就是将 Web 服务引用的“URL 行 为”属性设置为“动态” 。这是首选方法。将属性设置为“动态”时，代理类中会添加一些代码， 以便从应用程序配置文件（对于 Web 应用程序是 Web.config，对于 Windows 应用程序则是 SomeApp.exe.config）的自定义配置部分中检索 Web 服务 URL。

z

也可以通过使用 WSDL.exe 命令行工具来生成代理，并指定 /urlkey 开关。其工作方式与设置 “URL 行为”属性类似，因为它也为代理添加代码来检索 Web 服务的 URL，但此时 URL 存 储在应用程序配置文件的 <applicationSettings> 部分中。

动态 URL 方法还使您能够提供一个用户配置文件，该文件可重写主应用程序配置文件。这使个别 开发人员和测试团队成员能够将一个 Web 服务引用临时重定向到其他位置。 如何使用动态 URL 和用户配置文件 将 Web 服务引用的“URL 行为”属性设置为“动态”可以在开发和生产环境中获得最大程度的配 置灵活性。默认情况下，在您添加 Web 引用时，Visual Studio 会将此属性设置为“动态”。要确 保此值被设置为“动态”： 1.

在“解决方案资源管理器”中，展开 Web 引用的列表。

2.

选择列表中的各 Web 引用。

3.

对于每一个 Web 引用，检查“URL 行为”属性的值是否被设置为“动态”。

要在一个用户配置文件中指定 Web 服务 URL： 1. 初次添加一个 Web 引用时，Visual Studio 自动为您生成 App.config 文件。此文件包含 Web 服 务引用，App.config 文件中的配置设置如下所示： <configuration> <configSections> <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name=" YourProject.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /> </sectionGroup> </configSections> <applicationSettings> <YourProject.Properties.Settings> <setting name="SomeService_ localhost _Service" serializeAs="String"> <value>http://localhost/someservice/Service.asmx</value> </setting> </ YourProject.Properties.Settings> </applicationSettings> </configuration>

此文件包含一个新的配置部分，供生成的代理使用。这个配置部分包含 Visual Studio 在生成该代 理时找到的 Web 服务的地址。

Visual Studio 还 会 将 URL 的 默 认 值 放 在 为 此 代 理 生 成 的 代 码 中 。 此 值 位 于 名 为 Settings.Designer.cs 的文件中。要查看此文件： 1.

2.

3.

在“解决方案资源管理器”中，右击 Web 服务。 选择“在对象浏览器中查看”。在“对象浏览器”中查找 YourProject.Properties 项，其 中 YourProject 是包含 Web 服务引用的项目名称。 展开 YourProject.Properties 然后双击“设置”。这回打开 Settings.Designer.cs 文件，其中 包含一行类似于以下形式的代码：

[global::System.Configuration.DefaultSettingValueAttribute("http://localhost:/webservice/Service.asmx")] 这是在未发现任何配置信息时为 Web 服务 URL 使用的默认值。 您往往需要更改所调用的 Web 服务的 URL。例如，您可能希望对计算机上本地运行的 Web 服务 进行测试，或者对测试环境中运行的 Web 服务的一个版本进行测试。生产 Web 服务的 URL 很有 可能不同于开发过程中使用的 URL。要管理各 URL，应在用户配置文件中指定 URL 值，此文件由 主 App.config 文件引用。用户配置文件的名称是随机的。以下示例使用 User.config 作为文件名， 以便明确用户的配置位于何处。 为创建 User.config 文件，请按以下步骤操作： 在“解决方案资源管理器”中，右击包含 Web 服务引用的项目，指向“添加”，然后单击“新 建项”。 2. 选择“应用程序配置文件”，将名称更改为 User.config，然后单击“添加” 。 3. 将 <YourProject.Properties.Settings> 元素设置从您的应用程序配置文件中 (App.config) 复制到 User.config 文件。此文件应该仅包含运行时重定向到的元素。删除 <?xml> 和 <configuration> 元素（如果有），如下例所示： <YourProject.Properties.Settings> <setting name="SomeService_localhost_Service" serializeAs="String"> <value>http://localhost/someservice/Service.asmx</value> </setting> </YourProject.Properties.Settings> 单独的开发人员应该根据需要设置其 User.config 文件的内容，以引用相应的 URL。现在需要指定 配置系统使用该 User.config 文件配置数据，而不是使用 App.config 文件。要实现这一点，必须 按照以下步骤更新 User.config 文件： 1. 向主应用程序配置文件的 <YourProject.Properties.Settings> 元素添加 configSource="user.config" 属性。该操作完成后，运行时从该段存取信息时将被重定向到 指定的用户配置文件。 2. 删除 <YourProject.Properties.Settings> 元素的内容。

1.

您的 App.config 应该类似以下内容： <?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" > <section name="YourProject.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />

</sectionGroup> </configSections> <applicationSettings> <yourProject.Properties.Settings configSource="user.config"> </ YourProject.Properties.Settings> </applicationSettings> </configuration>

在上述示例中，YourProject 是包含 Web 服务引用的项目的名称。 重点：如 果 您 使 用 了 configSource 属性，则 用户配置文件必须出现，且仅可带有 <YourProject.Properties.Service> 元素。您还必须确保在添加 configSource=”user.config” 属性时， 从 <YourProject.Properties.Service> 元素中删除了可扩展标记语言 (XML) 内容。 在使用 User.config 方法时： z

应确保随应用程序一起部署您的 User.config 文件。为此，在“解决方案资源管理器”中右击 User.config 文件，单击“属性”选项，然后将“复制到输出目录”属性设置为“更新则复制” 。

z

不要将 User.config 文件添加到源代码管理中。通过这样的方法，所有开发人员和测试团队即 可使用自己的 User.config 文件，显式地绑定到特定的 URL。源代码管理可包含其他 User.config 文件，例如，用于测试和生产。这些文件应由负责管理测试和生产环境的用户管理。 这些测试和生产 User.config 文件不应作为 Web 服务项目的组成部分存储，而是应存储在源代 码管理系统的不同区域中。

z

在源代码管理中存储全局 User.config 文件。这可能仅包含根元素（无 <setting> 元素），也 可能指定了 Web 服务的默认位置。要使配置系统正常工作，User.config 文件必须出现。

提示：默认情况下，添加解决方案时，用户配置文件会自动添加到源代码管理中。为避免出现这种 情况，首次签入文件时，清除 User.config 文件复选框。可以在“解决方案资源管理器”中右击文 件，然后选择“在挂起的更改下”选项，确保文件受源代码管理控制。 重点：如 果 指 定 U R L 的 User.config 文件仅包含根元素，没有 User.config 中的设置元素， Web 服务代理就会为 URL 使用其默认值。这个默认值在一个名为 Settings.Designer.cs 的文件中硬 编码于代理内。该值作为 DefaultValueSettings 属性指定，形式如下： [global::System.Configuration.DefaultSettingValueAttribute("http://localhost/webservice/Service.asmx")]

重点：默认情况下，对于使用用户配置文件的 Web 应用程序，对文件所做的任何更改都会导致 Web 应用程序自动循环。如 果 不 希 望 在 值 发 生 更 改 时 循 环 应 用 程 序 ， 向 配 置 部 分 的 定 义 添 加 restartOnExternalChanges="false" 属性，如下所示： <configSections> <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561 934e089"> <section name="Test.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561 934e089" requirePermission="false" restartOnExternalChanges="true"/> </sectionGroup>

</configSections>

如 果 您 将 该 属 性 添 加 到 了 Web.config 文件的配置部分中，对外部 User.config 配置文件所做 的任何更改都不会导致 Web 应用程序循环。然而，那些更改对应用程序依然是可见的。 有必要了解，如果您正在使用这种机制，那么 User.config 文件就必须出现。必须有人负责，确保 在为产品发布和任何测试环境创建生成时的正确性。作为这个生成设置的一部分，还必须从源代 码管理系统检索恰当的 User.confg 文件，并将其复制到正确的位置，使 MSBuild 能够找到它。

引用数据库 以连接字符串的形式出现的数据库引用也可通过使用外部配置文件进行管理。这种方法的优势在于： 每个开发人员都能在自己的私有 User.config 文件中轻松指定自己的连接字符串。一名开发人员作出 的任何更改，例如为单元测试的目的将连接重定向到本地数据库，都不会影响其他开发人员。 用户配置文件还可用于管理特定于环境的设置，例如测试环境所需要的设置。测试环境也可以使用引 用测试数据库的 User.config 文件。 过程类似于之前的 Web 引用示例，差别在于，Web 服务代理的示例中包含从配置文件检索 Web 服务 URL 的代码。对于数据库连接字符串，您必须提供代码来读取连接字符串。

如何为数据库连接字符串使用用户配置文件 以下过程解释了如何在用户配置文件内存储并引用数据库连接字符串。 要使用用户配置文件来存储数据库连接字符串：

1.

为主应用程序配置文件的 <connectionStrings> 元素添加一个 configSource="user.config" 属性。 <configuration> <connectionStrings </configuration>

2.

configSource=”user.config”/>

要重写主应用程序配置文件，创建一个 User.config 文件（与应用程序配置文件位于相同的 文件夹内），然后向文件添加一条类似的 <connectionStrings> 项。注意，以下连接字符串引 用了一个本地数据库。 <connectionStrings> <add name="DBConnStr" connectionString="server=localhost;Integrated </connectionStrings> </configuration>

3.

Security=SSPI;database=Accounts"/>

在您的项目内，使用以下代码从用户配置文件获取连接字符串。此代码使用了 System.Configuration.ConfigurationManager 类 的 静 态 Connection Strings 属 性 。 在 WinForm 应用程序中，您必显式添加一个对 System.Configuration.dll 的引用。 using System.Configuration;

private string GetDBaseConnectionString() { return ConfigurationManager.ConnectionStrings ["DBConnStr"] .ConnectionString; }

4. 确保 User.config 文件随应用程序代码一起部署。为此，在“解决方案资源管理器”中右击 User.config 文件，单击“属性”选项，然后在“属性”窗格中将“复制到输出目录”属性设置 为“更新则复制”。 不要将 User.config 文件添加到源代码管理中。通过这样的方法，所有开发人员和测试团队即 可通过自己的 User.config 文件显式指定连接字符串。源代码管理可包含其他 User.config 文件， 例如，用于测试和生产。这些文件应由负责管理测试和生产环境的用户管理。这些测试和生成 User.config 文件 uying 作为数据库项目的组成部分存储，而是应存储在源代码管理系统的不同区 域中。 源代码管理中应有一个 User.config 文件，用于所使用的各种环境，例如生产和测试。这些配 置文件应指定数据库连接字符串。要使配置系统正常工作，User.config 文件必须出现。 提示：默认情况下，添加解决方案时，用户配置文件会自动添加到源代码管理中。为避免出现这种 情况，首次签入文件时，清除 User.config 文件复选框。随后可以在“解决方案资源管理器”中右 击文件，然后选择“在挂起的更改下”选项，确保文件不会归入源代码管理。 有必要了解，如果您正在使用这种机制，那么 User.config 文件就必须出现。必须有人负责，确保在 为产品发布和任何测试环境创建生成时的正确性。作为这个生成设置的一部分，还必须从源代码管 理系统检索恰当的 User.confg 文件，并将其复制到正确的位置，使 MSBuild 能够找到它。

小结 管理项目或第三方程序集时，您可以使用分支或工作区映射。分支是首选方法，因为它在源代 码管理服务器上存储依赖项关系。使用分支使您能够作出获取更新的二进制文件或源代码的明 智决策。 工作区映射是仅适用于客户端的方法，也就是说，您和所有开发人员都必须在自己的计算机和生成 服务器上创建映射，这样才能成功生成应用程序。您希望在生成时即时获取更新的二进制文件或源代 码时，这种方法最常用。 在引用 Web 服务时使用动态 URL，并使用一个外部配置文件来管理 Web 服务。这种方法的优势在 于：每个开发人员都能在自己的私有 User.config 文件中轻松指定自己的 Web 服务引用。还可以通过 使用外部配置文件管理以连接字符串的形式出现的数据库引用。这种方法的优势在于：每个开发人员 都能在自己的私有 User.config 文件中轻松指定自己的连接字符串。

其他资源 z

关于项目引用的更多信息，请参见“项目引用” ，地址为： http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx

z

关于分支的更多信息，请参见“如何：分支文件和文件夹” ，地址为： http://msdn2.microsoft.com/en-us/library/ms 181 425(VS. 80).aspx

z

关于工作区的更多信息，请参见“使用源代码管理工作区” ，地址为

http://msdn2.microsoft.com/en-us/library/ms 181383(VS. 80).aspx

第 III 部分 生成 本节内容： ¾ Team Build 详解 ¾ 使用 Team Build 设置连续的集成 ¾ 使用 Team Build 设置预定生成

第 7 章 - Team Build 详解 目标 z z z z z

理解 Microsoft® Visual Studio® Team System Team Build 体系结构。 了解构成 Team Build 的组件。 理解 Team Build 提供的功能。 选择一种恰当的生成策略。 确定在参与大型项目时可能需要更改生成策略的几种情况。

概述 这一章说明可如何使用 Team Build 来自动化生成过程。本章列举了一些与生成相关的常见障碍， 还比较了各种生成方法，从每日的预定生成到连续集成生成。 Team Build 构建于 Microsoft Build Engine (MSBuild) 之上，您可以使用它来检索生成所必须的源代 码、编译解决方案以及（如有必要）将单元测试和静态分析工具作为生成过程的一部分执行。您还 可以将生成输出发布到指定共享位置。 Team Build 使用生成号标记用于特定生成的源代码，使您能在将来任何时候检索创建特定生成所需 的源代码。如果出现故障，可以配置 Team Build 来创建工作项，并通知用户遇到的生成故障。

如何使用本章 使用这一章来了解 Team Build 为自动化和管理生成过程提供的功能，并理解用于预定生成的各种 策略。要从本章中获得最大收益，您应该： z z z

阅读“第 8 章 – 使用 Team Build 设置连续的集成”，了解使用 Team Foundation Server (TFS) 实现连续的集成的更多信息。 阅读“第 9 章 – 使用 Team Build 设置预定生成”，了解使用预定生成的更多信息。 阅读附带的“如何”文章，帮助您执行与生成相关的任务： 如何：使用 Team Build 在 Visual Studio Team Foundation Server 中自动运行代码分析 如何：在 Visual Studio Team Foundation Server 中设置连续集成生成 如何：在 Visual Studio Team Foundation Server 中设置预定生成

体系结构 这一节介绍 Team Build 的体系结构，分别描述其物理体系结构和逻辑工作流。

物理体系结构 Team Build 的物理体系结构包含以下组件： z z z z

新 Team Build 类型创建向导 – 这个客户端组件可通过“团队资源管理器”访问，使您能够创 建新生成类型。 团队生成浏览器 – 这个客户端组件可通过“团队资源管理器”访问，使您能够在“团队资源管 理器”中查看 Team Build 报告和生成过程信息。 源代码管理 Web 服务 – 这个应用层组件由生成服务用于访问源代码。 Team Foundation Build Web 服务 – 这个应用层组件接受来自客户端的请求，并调整生成步骤 的执行。

z z z

生成服务 – 此服务运行生成步骤，作为对 Team Build Web 服务的指令的响应。可以将生成服 务放置在一个单独的生成服务器上，也可将其放置在应用层服务器上。 Team Foundation Build 存储 – 这个数据层组件用于保存与 Team Build 过程相关的记录。 源代码数据库 – 这个数据层组件用于存储生成服务在生成过程中访问的源代码。

逻辑工作流 图 7.1 展示了 Team Build 逻辑工作流。

图 7.1 Team Build 逻辑工作流 Team Build 通过应用层与 TFS 相集成，并与工作项、代码覆盖、代码分析、测试用例和报告交互。 TFSBuild.proj 文件控制生成，包括要生成哪些项目、配置、放置位置、代码分析和要运行的测试。 此文件由“新 Team Build 类型创建向导”在生成初次创建时生成。可以直接编辑此文件。 Team Build 使用 TFS 中的事件系统。可以使用 Team Build 触发的事件来创建自定义生成步骤， 或生成关于生成状态变更或生成完成的通知。

要点 应始终牢记以下一些与 Team Build 物理体系结构相关的要点： z z z

Team Foundation Build 构建于 MSBuild 之上。 TFSBuild.proj 文件包含所有生成设置。通过使用“新 Team Build 类型创建向导”生成此文件。 随后可以直接编辑此文件。 TFSBuild.rsp 文件包含 MSBuild 的命令行选项。可以修改此文件，进一步自定义生成。

z z

事件通知通过 BuildStatusChangeEvent 和 BuildCompletionEvent事件实现自定义生成步骤或 通知。 Team Build 与工作项、代码覆盖、代码分析和测试用例相集成。

Team Build 工作原理 Team Build 包含位于 MSBuild 生成系统之上的团队生成服务。MSBuild 负责生成本身，而团队生 成服务负责与 TFS 应用层通信。Team Builds 通过 Visual Studio 客户端创建，您可以使用生成服 务器上的事件通过客户端启动它，也可以通过命令行启动，例如作为预定任务。一旦启动，生成过 程包含以下步骤： 1.

2.

3.

4.

5.

6.

7.

8.

将源代码管理中的源代码获取到生成目录中。 编译源代码并生成二进制文件。 运行代码分析（可选）。 如果存在生成故障，创建一个工作项。 运行测试（可选）。 计算代码覆盖（可选）。 记录生成细节。 将生成复制到放置位置。

生成完成后，有以下内容可用： 生成细节。可以通过任何客户端或报告查看细节。 生成二进制文件。二进制文件位于放置位置。 生成日志。可以在日志中查看错误和警告。 工作项。如果生成失败，则创建一个工作项来跟踪生成中断。

如何确定生成策略 使用以下步骤来确定生成战略： 1.

2.

3.

考虑生成的消费者。 回顾解决方案场景。 了解常见障碍。

考虑生成的消费者 大多数开发团队都有以下一种或几种生成消费者： z z z z z

开发团队。 测试团队。 内部生成采用者。 外部测试版采用者。 客户。

每种消费者在生成质量和频率方面都有不同的需求。通常，生成消费者可划分为两大组：需要可预 计、预定生成的一组；需要快速、事件驱动型生成的一组。预定生成通常是每日生成，但也可以采 用更高或更低的频率。事件驱动的生成通常以签入开始，设计用于为开发团队提供快速反馈。如果 您的开发团队有生成中断的问题，可考虑使用控制门式签入模型，在这种模型中，签入会首先得到 测试，之后才允许进入源代码树，若测试失败，则拒绝签入。

回顾解决方案场景 根据解决方案场景的目标和生成消费者与您的团队的环境匹配的情况选择解决方案场景。如果不确 定，应尽可能使用最简单的生成方案，例如预定生成，仅在必要时才使用更复杂的方案。 生成方案。 下面列举了最常见的 Team Build 方案： z z

z

使用一个每日生成的团队。大多数团队都依靠预定生成来为测试团队和其他用户提供一致的二 进制文件。 使用每日生成和连续集成生成的团队。有些团队会选择使用连续集成生成，以在每次签入时为 开发人员提供快速反馈。尽管纯粹的连续集成生成很适合小型团队，但较大的团队也很可能因 高频率的签入和较长的生成时间而使生成服务器超载。这种情况发生时，可以使用滚动式生成 来降低生成频率，同时不必在签入和生成反馈间浪费过长的时间。 具有多个生成实验室的团队，均执行每日生成和连续集成生成。规模极大的团队很可能需要更 加复杂的解决方案，以改进生成质量和及时性。可以使用控制门式签入，通过在错误的签入进 入源代码管理之前拒绝这些签入，从而减少生成中断。进行过分支的团队可以使用多个生成服 务器，每个分支一个，以保证生成集中关注各分支的目的。例如，集成分支创建集成生成，而 开发分支创建开发生成。

预定生成 预定生成是基于时间的生成，以固定的时间频率为依据。预定生成的目的在于产生一致、可靠的生 成，用于获取关于生成质量的反馈。预定生成通常是每日生成，但也可根据您的需求采用更高或更 低的频率。 预定生成的消费者往往包括： z z z

测试团队。 内部生成采用者。 外部采用者。

使用以下步骤来创建预定生成： 1.

2.

使用命令行生成创建一个批处理文件。 使用 Windows 任务计划按时间表执行批处理文件。

有关更多信息，请参见“第 9 章 – 使用 Team Build 设置预定生成”。

连续集成生成 连续集成生成会在签入发生时被触发。连续集成生成的目的在于在签入后尽可能快地获取关于生成 质量的快速反馈。开发团队是连续集成生成的典型消费者。 根据团队的具体规模、生成的长度、签入的数量，选择以下策略之一： 1.

2.

每次签入后立即执行连续集成生成。 在指定签入数或指定时间段（无论哪个条件先满足）之后执行滚动式生成。

关于更多信息，请参见本指南中的“第 8 章 – 使用 Team Build 设置连续集成生成”。

控制门式签入 控制门式签入是一种要求每次签入满足某些质量标准后才可加入源代码树的过程。控制门式签入要

求每次签入先通过一系列测试，之后才能被接受，目的在于减少生成中断的数量，并改进生成质量。

了解常见障碍 存在一些 Team Build 默认不支持的常见场景。请查看以下场景，考虑您的团队是否有可能面对其 中的某个场景： z

z

z

z

使用外部依赖项生成项目。如果使用了分支将外部依赖项引入您的团队项目，那么可以使用项 目引用，生成将在生成服务器上运行，无需任何额外的步骤。如果使用客户端工作区映射来引 用外部依赖项，则需要在生成服务器上维护映射，以使生成成功完成。更多相关信息，请参见 “第 6 章 – 在 Visual Studio Team System 中管理源代码管理依赖项”。 生成设置项目。Team Build 默认情况下不支持设置项目。使用自定义的生成后步骤来编译设置 项目，并将二进制文件复制到生成放置位置。有关更多信息，请参见“演练：配置 Team Foundation Build 来生成 Visual Studio 设置项目”，地址为： http://msdn2.microsoft.com/en-us/library/ms404859(VS.80).aspx 生成 .NET 1.1 应用程序。Team Build 默认情况下不支持 .NET 1.1 应用程序。MSBuild Extras – Toolkit for .NET 1.1 (MSBee) 支持 .NET 1.1 生成，但要求您的项目和解决方案升级到 Visual Studio 2005。如果无法升级为 Visual Studio 2005 项目和解决方案，可以使用一个自定义的生成 后步骤来编译 .NET 1.1 应用程序。要下载 MSBee，请访问 http://www.codeplex.com/MSBee。 关于创建自定义生成步骤编译 .NET 1.1 应用程序的更多信息，请参见 Nagaraju 的博客文章， 地址为：http://blogs.msdn.com/nagarajp/archive/2005/10/26/485368.aspx，或查看“Microsoft SDC DevEnv 任务”，地址为： http://www.codeplex.com/sdctasks。 生成 Microsoft Visual Basic® 6.0 应用程序。Team Build 默认情况下不支持 Visual Basic 6.0 应用程序。使用自定义生成后步骤来编译 Visual Basic 6.0 应用程序。要查看与编译 .NET 1.1 应 用程序类似的生成后步骤，请查看 Nagaraju 的博客文章，地址为： http://blogs.msdn.com/nagarajp/archive/2005/10/26/485368.aspx，或查看“生成 VB6 的 MSBuild 任务”，地址为：http://freetodev.spaces.live.com/blog/cns!EC3C8F2028D842D5!261.entry。

大型项目考虑事项 如果在大型开发团队中工作，则有一些其他考虑事项需要注意。大型开发团队通常与小型团队有以 下差别： z z z

需要更复杂的分支与合并结构。 很可能要跨解决方案和团队项目管理依赖项。 很可能要维护多个组件和团队的生成。

在应对大型开发团队时，应注意以下事项： z z z

大型团队很可能要付出更长的生成时间。连续集成生成的频率应低于生成频率，以避免生成服 务器的过多排队与加载操作。 如果您的团队进行了分支，可以为每个分支设置一个生成服务器。这使各生成能够集中关注分 支的目的，例如集成或开发。 集成分支可能仅有预定生成。开发分支可能有连续集成生成和预定生成。

生成自定义 要修改关于生成的信息，例如生成服务器、放置位置或生成目录，可以编辑 TFSBuild.proj 文件。 TFSBuild.proj 文件包含执行团队生成所需的大部分信息。这种信息包括生成位置和生成是否应执行 静态代码分析并运行单元测试。要修改生成，可以编辑TFSBuild.proj 文件。要编辑该文件： 1.

将文件签出源代码管理。

2.

3.

在文件中更新生成信息。 重新签入文件，提交更改。

下一次执行生成时，将使用修改后的生成数据。 关于自定义生成的更多信息，请参见本指南中“生成指南”和“生成实践”中的“自定义”。

小结 Team Build 构建于 MSBuild 之上。它通过应用层与 TFS 相集成，并与工作项、代码覆盖、代码分 析、测试用例和报告功能交互。 确定生成策略时，您需要考虑生成消费者和生成需求。常见的生成策略包括：为获得可供测试团队 和其他角色用于提供关于生成质量的反馈的一致、可靠的生成使用预定生成；为使开发团队获得关 于生成质量的快速反馈使用连续集成生成。

其他资源 z

关于 Team Build 的更多信息，请参见“Team Foundation Build 概述”，地址为： http://msdn2.microsoft.com/en-us/library/ms181710(vs. 80).aspx

第 8 章 – 使用 Team Build 设置连续的集成 目标 z z z

了解连续集成生成的目标。 使用 Microsoft® Visual Studio® Team System Team Build 设置连续的集成。 优化连续集成生成来减少瓶颈。

概述 这一章解释了如何使用 Team Build 和 Microsoft Visual Studio Team Foundation Server (TFS) 设置 连续集成生成。使用连续集成生成在签入之后尽可能迅速地获得关于生成质量的反馈。在团队开发 过程中，有必要获得关于签入质量的快速反馈，特别是在它们与其他开发人员的更改相结合并中断 生成时。连续集成生成使您有机会快速修订代码，以避免妨碍其他团队程序，从而改进生成的一致 性和质量。 Team Foundation Server 默认情况下并不支持连续集成生成。借助于 Microsoft 提供的扩展，就有可 能扩展生成引擎，支持连续的集成。

如何使用本章 使用这一章来学习用于连续的集成的策略，并了解如何使用 Team Build 来设置和配置连续集成生 成。关于帮助您设置连续集成生成的详尽指导，请参见“如何：设置连续集成生成”。 如果您是 TFS 和 Team Build 新手，或者希望了解更多可用于自动化和预定生成的选项，请阅读“第 7 章 – Team Build 详解”，之后再阅读这一章。

用于连续集成生成的策略 连续的集成 (CI) 是在开发人员将代码签入源代码管理时创建生成的过程。以下列表确定了用于连续 集成生成的各种策略： z z z z

在每次签入时生成。 在指定签入数之后执行滚动式生成。 在指定时间间隔后执行滚动式生成。 在指定签入数或时间间隔后执行滚动式生成。

每次签入时生成 在每次签入后立即执行生成是最简单的连续集成策略，通常会给予您最快速的反馈。然而，如果签 入的速度足够快，拥塞生成服务器，则应使用滚动式生成方法，在指定签入次数或指定时间段后生 成。要决定是否使用滚动式生成，先确定以下几个方面： z z z

以分钟计算的团队生成长度。 以分钟计算的平均签入频率。 确定签入发生频率的时间窗口。

如果生成的长度大于签入的平均频率，生成将开始排队，因为第一个生成要等到下一次签入发生时

才会完成，而这次签入又会启动另一次生成。如果生成队列足够长，就会影响生成服务器的性能， 并使其他生成无法开始，例如预定生成。检查签入发生频率的时间窗口，确定最繁忙的签入阶段结 束后，队列是否有时间清空自己。 有关更多信息，请参见“如何：在 Visual Studio Team Foundation Server 中设置连续集成生成”。

在指定签入数之后执行滚动式生成 如果您的生成服务器因在每次签入后创建生成而超载，可以选择仅在指定签入数完成后执行生成。 虽然这是最简单的滚动式生成解决方案，但它也有着明显的缺陷。由于生成服务器必须看到指定数 量的签入，之后才能开始一次生成，因此当日的最后一次签入实际上并不保证能获得一次生成，因 此生成反馈也会延迟。

在指定时间间隔后执行滚动式生成 仅在每次签入的指定时间间隔后执行生成，这是对特定签入数后生成的改进。这种方法保证了在每 次签入执行为中心的指定时间帧内产生一个生成。切记，每次生成都有不同数量的相关签入——某 些生成可能仅有一个签入，而且其他一些生成有多个签入与之相关。一个生成中的签入数越多，确 定哪次签入造成了中断性变更的难度就越大。

在指定签入数或时间间隔后执行滚动式生成 在指定时间间隔或签入数（视先满足哪个条件而定）产生生成，可以在滚动式生成中得到最高的一 致性，同时也会降低生成服务器负载。如果连续集成生成会造成非常长的生成队列，并导致生成在 签入的很长一段时间以后才发生，则可使用滚动式生成。使用签入时间间隔来指定每次生成之间的 签入数。使用超时阶段来确保生成发生，即便没有额外签入也能发生。

确定滚动式生成时间间隔 要确定理想的滚动式生成时间间隔，用生成的长度除以签入的平均频率。例如，如果有一个占用 10 分钟的生成，而您平均每 5 分钟签入一次，那么可以设置两次签入的签入间隔、10 分钟的超时阶 段。这有助于确保生成在下一次生成开始之前完成。如果发现生成服务器上有过剩负载，可以增加 这些值。

在 Team Foundation Server 中执行连续集成生成 Team Foundation Server 2005 未提供开箱即用的连续集成解决方案，但确实为您提供了一种框架，可 实现自己的连续集成生成解决方案。 关于使用 TFS 设置连续集成生成的更多信息，请参见“如何：在 Visual Studio Team Foundation Server 中设置连续集成生成。”这篇“如何”文章使用了 Visual Studio Team System 开发团队提供 的解决方案。该解决方案会安装一个 Web 服务，在有权访问 TFS 服务器的账户下运行。Team Foundation Server 能够在特定事件发生时发送电子邮件消息或调用 Web 服务。这种事件机制由连 续的集成解决方案使用，用于向 CheckinEvent 注册一个 Web 服务，这样在签入发生时，该Web 服 务就会启动一次团队生成。

小结 在开发人员将代码签入源代码管理时，使用连续集成生成来取消一次生成。尽管 Team Build 未提 供开箱即用的连续集成解决方案，但您可以自定义生成并实现自己的连续集成生成解决方案。 根据具体项目需求的不同，可以如下设置连续集成生成： z

在每次签入时执行连续集成生成。

z

在指定签入数或指定时间间隔后（无论哪个条件先满足）执行滚动式生成，以减少生成服务器 的负载。

其他资源 z

z

z

关于如何使用 Visual Studio Team System 连续集成解决方案的更多信息，请参见“使用 Team Foundation Build 执行连续集成”，地址为： http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx 要下载 Visual Studio Team System 连续集成解决方案 MSI，请访问： http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ ci.msi 关于 TFS 中的敏捷开发和连续集成的更多信息，请参见“扩展 Team Foundation Server 来实 现连续的集成”，地址为： http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx

第 9 章 – 使用 Team Build 设置预定生成 目标 z z

了解预定生成的目标。 使用 Microsoft® Visual Studio® Team System Team Build 设置预定生成。

概述 这一章解释了如何使用 Team Build 和 Microsoft Visual Studio Team Foundation Server (TFS) 设置 预定生成。预定生成的目标在于自动化按照一致的时间表创建可靠生成的过程。这是测试团队、内 部采用者和外部测试版用户最常使用的生成类型。 预定生成是生成自动化的最简单形式。您可以将预定生成配置为每小时、每日、每周运行，或者任 何最适合您的团队的时间间隔。

如何使用本章 使用这一章来学习用于预定生成的策略，并了解如何使用 Team Build 来设置和配置预定生成。关 于帮助您设置预定的详尽指导，请参见“如何：设置预定生成”。 如果您是 TFS 和 Team Build 新手，或者希望了解更多可用于自动化和预定生成的选项，请阅读 “第 7 章 – Team Build 详解”，之后再阅读这一章。 如果您关注由开发团队签入的代码的质量所导致的生成不稳定问题，则应考虑使用连续集成生成。 关于连续生成的更多信息，请参见本指南中的“第 8 章 – 使用 Team Build 设置连续集成生成”。

预定生成频率策略 在创建预定生成时，生成的频率是需要制定的一项重要决策。可以选择以每小时、每夜或每周为基 础预定生成。

每小时生成 如果您正致力于一个有足够多签入的项目，足以导致在一个小时内发生重大更改，而且您又不希望 使用连续集成生成，则可选择每小时生成频率。每小时生成可以为开发人员提供快速的反馈，并可 由测试人员和其他团队成员用于请求其反馈。

每夜生成 这是最常用的预定生成频率，因为它在每天早上为您的测试和开发团队提供一个新生成，整合了前 一天的更改，而且随时可供测试。

每周生成 如果您正致力于一个大型、复杂的项目，而生成时间可能持续数日，则应选择每周生成。这确保了 您的测试团队在每周一开始就有一个生成整合了上一周的更改，而且随时可供测试。

在 Team Foundation Server 中执行预定生成 TFS 中的 Team Build 功能不支持通过用户界面设置预定生成。反之，您可以使用 Microsoft

Windows® 任务计划工具运行 TFSBuild 命令实用工具，在预定时间启动生成。 使用以下步骤来创建预定生成： 1.

创建如下 TFSBuild 命令行。TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>

2.

将该命令行放置在一个批处理文件中。请注意，必须指定 TFSBuild.exe 文件的完整路径，使之 可通过 Windows 命令提示符运行。批处理文件中使用的命令示例如下： "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TFSBuild" start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>>

3.

创建一个 Windows 任务计划，按照所需时间间隔运行这个批处理文件。

有关更多信息，请参见“如何：在 Visual Studio Team Foundation Server 中设置预定生成”。

小结 使用预定生成来产生可给与测试团队或可以提供关于生成质量的反馈的任何生成消费者的一致生 成。Team Foundation Server 并未通过其用户界面提供预定生成支持。反之，您可以使用 Windows 任 务计划工具运行 TFSBuild 命令实用工具，在预定时间启动生成。 您可以将预定生成配置为每小时、每日、每周运行，或者任何最适合您的项目的时间间隔。

其他资源 z 关于设置预定生成的信息，请参见“如何：配置预定生成（命令行）”，地址为： http://msdn2.microsoft.com/en-us/library/ms181727(VS.80).aspx

第 IV 部分 大型项目考虑事项 本节内容： ¾ 大型项目考虑事项

第 10 章 - 大型项目考虑事项 目标 z z z z z

理解 Microsoft® Visual Studio® Team System Team Foundation Server (TFS) 中的大型项目工作 流。 了解如何为大型团队优化源代码管理和生成。 了解大型项目会对源代码管理产生怎样的影响。 了解在参与大型项目时，分支和合并策略会需要怎样的更改。 了解大型项目会对生成策略产生怎样的影响。

概述 本章描述了大规模 TFS 开发工作的额外考虑事项。大型项目通常与小型项目有以下一些差别： z z z

需要更复杂的分支与合并结构。 必须处理跨解决方案和团队项目的大量依赖项。 很可能要维护多个组件和团队的生成。

例如，在一个大型项目中，您可能需要支持多个分支，以便支持多个功能团队的平行开发工作。在 这种情况下，您很可能需要跨解决方案和团队项目管理依赖项，并共享公共 Web 服务和数据库。 每个子团队都可能需要维护自己的生成服务器，并将生成输出到指定放置位置。

如何使用本章 如果您需要管理、支持或参与大规模的开发项目，可以使用这一章。第 3、5、7 章还提供了具体的 “大型项目考虑事项”节。使用这一章在一处回顾所有大型项目考虑事项。

大型项目的逻辑工作流 图 10.1 展示了多个子团队协调工作产生一个复杂应用程序的常见方案。

图 10.1 大型项目方案

图 10.1 突出显示了大型团队操作的一些要点： z z z

每个子团队都维护自己的生成服务器，并将生成输出到一个放置位置。 应用程序团队从组件团队获取生成，将其作为解决方案的一部分重用，并包含在自己的生成中。 对每个生成执行组件和集成测试。Bug 归入恰当的 bug 数据库。

源代码管理考虑事项 如果您参与一个非常大的解决方案，需要数十个项目，那么可能会遇到 Visual Studio 解决方案 (.sln) 可伸缩性限制。出于这方面的原因，应按子系统或子应用程序组织源代码管理结构，并使用多个解 决方案文件。将应用程序划分为多个解决方案，但不要为整个应用程序创建主解决方案。图 10.2 展 示了大型团队常用的多解决方案方法。

解决方案 1

项目 A

解决方案 2

项目 B

项目 C

项目 D

内部系统 边界

外部系统 边界

项目 E

外部 程序集 第三方 组件

项目 F 解决方案 3

文件引用 项目引用

图 10.2 多解决方案方法 在这种情况下，各解决方案内部的所有引用都是项目引用。对各解决方案外部的项目的引用（例如， 另一个子解决方案中的第三方库或项目）是文件引用。这就意味着，不存在任何“主”解决方案。 反之，您必须使用一个了解解决方案所需生成次序的脚本。 与多解决方案结构相关联的维护任务之一就是确保开发人员不会无意中在解决方案间创建循环引 用。这种结构需要复杂的生成脚本，以及依赖项关系的显式映射。在这种结构中，应用程序不可能 完全在 Visual Studio 内生成。而应使用 TFS Team Build。 关于这种多解决方案方法的更多信息，请参见本指南的“第 3 章 – 在源代码管理中设计项目和解 决方案的结构”。

分支和合并考虑事项 大型团队很可能要同时按团队和功能分支，也有可能有一个或多个专门用于集成外部依赖项的分支。

分支结构越深，开发分支中出现更改与该更改合并入主集成分支间的延时也就更长。处于这方面的 原因，应该在创建分支时谨慎考虑合并策略。 例如，在决定选择预定合并还是事件驱动型合并时，考虑以下几个方面： z z

反向集成通常是预定的，例如从开发分支到主集成分支的合并。 正向集成（如从主集成分支到开发分支的合并）通常是基于事件的，例如一个功能里程碑完成。 此事件在负责开发分支的团队认为自己已经准备好合并来自其父分支的更改时发生。

借助您希望产生生成的频率合理设置分支/合并策略。较深的分支结构会导致从子分支到主集成分支 的合并时间更长。这种情况给您的开发团队导致问题的征兆包括： z z z

如果修订传播到主集成分支的时间过长，那么就应该拆分生成。 由于功能传播到主分支的时间过长，导致里程碑丢失。 花费了大量时间在各分支间合并更改。

如果这对您的团队成为了问题，考虑减少分支结构的深度。 下面是大型团队分支结构的一个示例： z

My Project Development – 分隔活动的开发分支的容器 Team 1 z Feature A – 用于开发的独立分支 Source Feature B – 用于开发的独立分支 Source Team 2 z Feature A – 用于开发的独立分支 Source z Feature B – 用于开发的独立分支 Source Main – 主集成和生成分支所有变化都汇聚于此。 Source 其他资产文件夹 Releases – 发布分支的容器 z Release 4 – 包含当前推行到发布的代码的分支 Source z Release 2– 活动的维护分支 Source z Release 3– 活动的维护分支 Source Safe Keeping z Release 1 – 安全保护中的旧发布 Source

此结构包括： z z z

用于使多个团队隔离工作的功能分支。 一个主分支，汇集所有团队作出的更改和来自发布分支的 bug 修订。 一个用于推行当前发布的发布分支。

z z

一个得到积极维护和支持的旧发布的维护分支。 不再维护的旧发布的保护分支。

生成考虑事项 大型团队很可能要付出更长的生成时间。连续集成生成的频率应地域生成频率，以避免生成服务器 的过多排队与加载操作。大型团队的生成系统通常组织如下： z z z z

如果团队使用多个团队或功能分支，则为每个分支使用一个专用生成服务器。这使团队能够使 其各生成能够集中关注分支的目的，例如集成或开发。 生成频率根据团队的需求决定。生成基础结构以支持这些需求为目的而设计和生成。 生成频率首先选定，然后以此目标为依据，确定合并频率。 预定生成通常用于集成分支。连续集成和预定生成相结合，用于开发分支。集成分支分配给集 成测试团队。来自开发分支预定生成的输出发送给相关的测试团队；开发分支连续集成生成为 特定开发团队提供相关反馈。

另外一个关键问题是：是否应在各集成点使用生成、测试和质量控制门。 除此之外，不必为主集成分支完成这些任务。理想情况下，应为每个分支使用一个生成服务器，以 及质量控制门连同支持的开发和测试团队。应注重实效，如果那种选项不存在，您可能需要移除质 量控制门或移除分支来简化您的结构。

小结 如果正在参与一个非常大的解决方案，需要数十个项目，那么可能会遇到 Visual Studio 解决方案 (.sln) 可伸缩性限制。如果确实如此，应按子系统或子应用程序组织源代码管理结构，并使用多个解 决方案文件。 对于大型团队，分支结构更深，因此应做好准备，一个开发分支中发生更改与这些更改合并回主集 成分支之间会有较长的延时。 大型团队很可能要付出更长的生成时间。连续集成生成的频率应低于生成频率，以避免生成服务器 的过多排队与加载操作。如果依然存在生成服务器性能方面的问题，应考虑在源代码管理结构中为 每个分支使用一个生成服务器。

其他资源 z z z z z z

z

关于 Team Foundation 源代码管理的更多信息，请参见“在 Team Foundation 中使用源代码管 理”，地址为： http://msdn2.microsoft.com/en-us/library/ms364074(VS.80).aspx 关于创建工作区的更多信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx 关于分支与合并的简介，请参见“分支与合并入门”，地址为： 关于分支的更多信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 关于合并的更多信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 关于如何在 Visual Studio 2005 中进行分支与合并的更多信息，请参见“对 Team Foundation 源代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx 关于 Team Build 的更多信息，请参见“Team Foundation Build 概述”，地址为： http://msdn2.microsoft.com/en-us/library/ms181710(vs.80).aspx

第 V 部分 项目管理 本节内容： ¾ 项目管理简介 ¾ 工作项简介

第 11 章 – 项目管理简介 目标 z z z

了解 Microsoft® Visual Studio® Team System (VSTS) 为项目经理提供了哪些功能。 为创建团队项目选择一种策略。 使用 Visual Studio Team System 创建和管理项目。

概述 这一章为您介绍了 Visual Studio Team System 提供的项目管理功能，以及它们会怎样帮助您克服与 管理软件开发项目相关的常见问题和挑战。 Visual Studio Team System 和 Team Foundation Server (TFS) 提供了工具、模板和报告，帮助您监控 和支持软件开发过程。因此，团队社区变得更简单，团队成员间的移交是自动化的、像任务之类的 工作项更易于分配和跟踪、表明项目健康状况和进展的指标更易于监控。

如何使用本章 使用这一章来了解 TFS 和 VSTS 中专门针对项目经理的具体功能。 z z z

阅读“项目管理概要”和“传统项目管理问题”这两节，了解 TFS 项目管理可能要解决的问 题。 阅读“团队项目策略”一节，确定用于团队项目创建和组织的策略。 使用其他几节更好地理解过程模板、工作项和其他项目管理功能。

项目管理概要 计划项目通常包括类似以下的步骤： 1.

2.

3.

4.

5.

6.

生成远景陈述。这一步涉及创建所需项目最终结果的视图，由项目的所有利益相关人共享。 生成方案。此步骤包含确定软件的初始使用方案集。这涉及使用客户输入。还涉及验证方案来 确保它们对您的客户有价值。 生成功能集来支持这些方案。此步骤包含将方案拆分成对您的客户有价值的具体项，使您可以 与客户讨论与这些项相关的具体期望。 生成工作项集。此步骤涉及将方案和功能拆分成特定的任务。换句话说，工作项完成时，相关 功能或方案也就得到了实现。 将任务拆分成区域。此步骤涉及将任务拆分成区域。这些区域可以是功能性的，也可以基于特 定团队的组织方式。 安排工作进度。此步骤涉及预先安排所有工作的进度，或者将工作拆分成迭代。

传统项目管理问题 当今的大多数项目经理都使用多种多样的工具来管理软件开发过程，而这些工具通常与软件开发人 员用于完成其工作的工具只有很少的集成甚至根本未集成。这种工具和团队间缺乏集成和内聚的事 实为项目经理带来了严峻的挑战。典型的问题包括：

z

z

z

z z

z

应对异构的信息源。项目管理工具通常独立使用，这导致了无法轻松集成的独立信息源。此外， 通常难以将由项目管理工具维护的数据与其他团队成员维护的数据（例如，一个独立 Bug 跟踪 数据库中跟踪的 bug）相集成以生成有意义的指标。 难以捕获与项目相关的指标。获得与项目相关的指标对于跟踪状态、制定明智的决策和回答“项 目能否按时、按预算交付？”之类的基本问题至关重要。要回答这些重要的问题，项目经理通 常要依靠从 Microsoft Office Project 或开发和测试团队所用 bug 跟踪系统中获取的数据。整合 来自这些异构系统的数据非常困难、耗时，也易于出错。工具生成的大多数指标无法以统一的 形式存储或访问。创建报告通常是一种手工密集型工作，需要在各种工具间执行大量的复制与 粘贴操作。 难以确保需求得到满足。在为开发团队计划的工作与客户需求和已确定的关键非功能需求之间 往往存在着鸿沟。而在预定工作与实际工作之间也存在鸿沟。重要的信息就在这样的鸿沟中丢 失，从而导致需求未得到满足。 管理过程和过程更改。与团队应采用的过程通信可能是一项极具挑战的任务。在不影响团队生 产率的前提下 实现更改来应对系统问题可能非常困难。 缺乏可审核的通信和任务跟踪。协作和团队内聚通常是通过照看团队会议来解决的，通过向开 发人员分配任务清单来帮助他们将精力集中于正确的优先事项。跟踪独立任务的过程是一大挑 战。此外，项目经理往往要花费大量宝贵的时间从各种项目和清单中收集状态信息。团队成员 也要付出时间来完成状态报告并更新各种文档和表单。 质量保证。预测软件中出现的 bug 数量和严重程度很困难，因此时间表预测和成本通常都只是 “最佳猜测”。这些预测往往会考虑应变指标，其数量通常依赖于项目经理对于项目当前健康 状态的信心。

VSTS 设计用于帮助解决项目经理面对的这些传统问题。为此，它提供了一组集成化工具，帮助团 队改进其软件开发活动，帮助项目经理更好地支持软件开发过程。

Team Foundation Server 中的项目管理功能 Visual Studio Team System 提供的关键项目管理功能包括： z

z z

z z z

过程管理。Team Foundation Server 过程管理包括 Microsoft Solution Framework (MSF) 过程指 南以及过程模板，它们使用工作项类型、报告、项目 SharePoint 门户和源代码管理设置来设置 新团队项目。 安全性和权限。新项目包含默认组和映射到通用开发团队角色的权限。 集中化工作项管理。包括 bug、风险、任务、方案和服务质量 (QoS) 需求在内的工作项在 TFS 工作项数据库中集中记录、管理和维护。集中存储将使所有团队成员可以更轻松地查看和访问 它们。 Microsoft Office Excel® 和 Microsoft Office Project 集成。通过使用 Office Excel 和 Office Project 集成功能，项目经理就可以继续使用已经了解的工具访问工作项存储库和时间表信息。 指标和报告。TFS 提供了报告服务，用于将操作数据（例如工作项、生成结果和测试结果）传 送到 TFS 数据仓库内存储的指标中。预定义的报告允许您查询多种项目健康和质量指标。 项目门户。对于每一个团队项目，TFS 创建一个相关项目门户，使用 Microsoft Windows SharePoint® 服务。使用该门户来管理与项目相关的文档，并快速查看关键报告，访问项目的当 前状态。

优势 TFS 的项目管理功能提供了以下优势： z z z z

集中化管理 高度可跟踪性 集成化项目计划和时间安排。 改进的过程控制

z z

改进的团都通信和内聚 准确的过程报告

使用 Team Foundation Server 创建和管理项目 以下步骤汇总了在 Team Foundation Server 中创建团队项目的一般方法： 1.

2.

3.

4.

5.

6.

7.

8.

9.

10.

11.

选择一种过程模板。可以使用开箱即用的默认模板，也可以自定义自己的模板。 创建一个团队项目。您的团队项目将以过程模板为基础。 向团队项目添加恰当的组和成员。 为项目确定迭代周期持续时间。这包括在团队项目中创建迭代。 在 TFS 中将方案作为工作项捕捉。 确定需为每次迭代完成哪些方案。 定义服务质量 (QoS) 需求。将服务质量需求链接到您的方案。 将方案拆分成小部分，为开发人员提供可管理的工作项。从开发人员处获取各工作项的预计。 创建项目时间表。创建一个项目时间表（使用 Microsoft Project），并将其添加到团队项目中。 定义验收标准。为工作项定义验收标准（与 QoS 相关联）。 定义报告需求。定义项目的关键性能指标，并确定报告需求。

关于创建和管理团队项目的更多信息，请参见“如何：在 Visual Studio Team Foundation Server 中管 理项目”

团队项目策略 您需要有至少一个团队项目，才能开始使用 TFS。一名项目经理创建了新的团队项目时，也会创建 一个相关的团队项目 Web 站点，其中包含带有文档模板的文档库和存储报告。工作项数据库创建 用于跟踪针对一个项目的所有工作，一种方法学模板被安装，确定所有工作的规则、策略、安全组 和查询。除此之外还会为源代码管理创建一个源代码分支。 您为团队项目选择的结构应以需求为准绳，并可以随开发过程的发展而变化。创建新团队项目时， 有三种常用策略。可以使用其中一种策略，也可以使用几种的混合。这三种常用策略是： z z z

每个应用程序一个团队项目 每个发布一个团队项目 每个团队一个团队项目

每个应用程序一个团队项目 这是创建团队项目的最常用策略。这种方法对于大型和小型应用程序都很有用，对于平行开发的多 个应用程序发布也很有用。通过这种方法，您会为正在开发的每个应用程序创建一个项目。

每个发布一个团队项目 这种方法对于正致力于长期项目的大型团队非常有用。在每一次主要发布后，您都会创建一个新项 目，有一个全新的起点。通过这种方法，您不必担心将上一次发布的包袱留到下一次，包括工作项 在内。同样，这种方法还给您带来了新机遇，使您可以改进过程模板，或根据最近获得的经验教训 使用新过程模板。

每个团队一个团队项目 这种方法对于跨多个团队的大型项目非常有用，对于这种项目，集中控制和活动监控非常重要。通 过这种方法，您会为每个团队创建一个项目。这种方法将团队与 TFS 工作项类型中定义的工作流 很好地协调起来，并提供了一个跨整个团队的报告单元。

过程管理 使用 VSTS，软件开发生命周期成为支持软件项目开发工作的工具的完整组成部分。通过将生命周 期过程集成到 VSTS 之中，开发团队交互的过程和移交就会得到工具的完全支持，并可在许多区域 中自动化。

过程模板 VSTS 使用过程模板定义指令集和工件，如过程指南文档、文档模板和默认工作项等待，以便设置 新项目。过程模板是独立指令集，为开发团队提供了软件开发计划的方法学。过程模板包含以下元 素： z z z z z

z

过程指南。这由各模板提供，并为需要协助开展或理解特定活动的团队成员提供上下文信息、 帮助和指示。过程指南集成到 Visual Studio 帮助系统之中。 文档模板。这些模板使团队成员能够以一致的方式创建新文档，如规范、风险评估和项目计划。 工作项和工作流。工作项有自己的字段和规则集，确定工作项的工作流和团队成员分配与执行 工作的方法。 安全组。这些组用于定义谁可以控制和操纵报告、工作成果，如源代码和文档以及工作项。项 目经理可以管理安全组，而无需成为 Windows 管理员。 签入策略。这些策略可用于为所有签入源代码管理的代码实施规则和质量控制门。例如，可以 强制要求签入的代码满足特定标准，例如符合公司的编码标准或通过单元测试。关于创建和配 置自定义签入策略的更多信息，请参见“如何在 Visual Studio Team Foundation Server 中创建自 定义签入策略”。 报告。用于监控项目的当前性能和状态。VSTS 附带许多预定义的报告，包括代码质量报告、 进度报告、测试有效性报告和其他许多。可以创建自己的报告并自定义现有报告。

MSF for Agile Software Development 和 MSF for CMMI Process Improvement 过程模板 以下两种过程模板是以开箱即用的方式提供的。 z z

MSF for Agile Software Development。这种用于小型、敏捷或非正式软件项目的轻量级过程模 板基于方案和上下文驱动的活动，以项目和人员为中心。 MSF for CMMI® Process Improvement。这一过程模板专为更为成熟的软件项目而设计。它提 供了对审核、验证和正式过程的支持，从而扩展了 MSF for Agile Software Development 过程模 板。它依赖于过程和过程一致性，以组织为中心。

如果已提供的模板不能很好地满足您的特定过程需求和方法学，可以为系统添加新的过程模板，还 可以自定义所提供的模板来满足组织的需求。关于自定义现有模板的更多信息，请参见“如何：在 Visual Studio Team Foundation Server 中自定义过程模板”。

安全性和权限 在 TFS 中创建项目时，无论选择了怎样的过程模板，都会为该项目创建四个默认组。默认情况下， 每个组都有一组为其定义的权限，监管这些组中有哪些成员得到以下授权： z z z z

项目管理员 贡献者 读者 生成服务。

可以为您的团队项目创建安全组，来满足组织的安全性需求。创建安全组是为一组用户授予团队项 目的指定权限集的有效方法。确保仅为该组授予了必要的最少权限，仅添加了必须属于这个新团队

项目组的用户或小组。 创建了一个团队项目组后，必须添加新组，为该组赋予恰当的权限，并将成员添加到组中。默认情 况下，一个团队项目组会在未许可任何特权的前提下创建。

工作项管理 工作项作为团队间通信和协作的工作单元使用。选定的过程模板提供了一个初始工作项类型集，项 目经理随后创建并管理需在开发项目中完成的更多工作项。一个工作项可能定义了任务、风险、方 案、bug、服务质量 (QoS) 需求。可以将工作项链接在一起，来提供更好的可跟踪性。例如，可将 一个具体的工作项任务与相关方案或与工作项关联的 QoS 需求联系在一起。 过程模板提供了工作项类型的定义，包括为各工作项类型定义的字段集。正因如此，过程模板的选 择非常重要，因为在项目的进展过程中无法进行修改。如有必要，应自定义过程模板，包含除基本 模板提供的工作项类型之外的其他工作项类型。 新建团队项目时，一系列的预定义工作项同时在 MSF for Agile Software Development 和 MSF for CMMI Process Improvement 过程模板中生成。这些工作项可用于“jumpstart”对过程的使用，它们 包含为启动软件开发过程而必须完成的任务。

MSF for Agile Software Development 过程模板 此过程模板提供的工作项类型包括： z z z z z

方案 – 用于表示与应用程序系统进行的用户交互。它记录达成目标所必须的具体步骤。编写方 案时，应确保具体，因为会有多种可行途径。 任务 – 用于表示需要执行的工作单元。每种角色都有自己的任务需求。例如，开发人员使用开 发任务来分配任务。 服务质量需求 – 用于归档系统特征，例如性能、负载、可用性、压力、可访问性和可服务性。 Bug – 用于在系统中通信潜在问题。 风险 – 用于标识和管理项目的固有风险。

MSF for CMMI® Process Improvement 过程模板 此过程模板提供的工作项类型包括： z z z z z z z

需求 – 用于捕获在需求收集阶段定义的需求。 变更请求 – 用于捕获在需求收集之后的任何变更请求。 问题 – 用于捕获项目中要跟踪的问题。 任务 – 用于表示需要执行的工作单元。每种角色都有自己的任务需求。例如，开发人员使用开 发任务来分配工作。 评审 – 用于表示项目中的评审工作单元，如代码评审、设计评审等。 Bug – 用于在系统中通信潜在问题。 风险 – 用于标识和管理项目的固有风险。

Microsoft Project 集成 安装 VSTS 或团队资源管理器应用程序会为 Microsoft Project 提供扩展。对于涉及大量资源的大型 项目，您可以使用 Microsoft Office Project，在 TFS 内操纵时间表数据。 例如，可以使用 Microsoft Project 管理和计划、分配、平衡和跟踪工作，然后在更新准备好供其他 团队成员使用时，将更新重新发布给工作项数据库。 有关更多信息，请参见“在 Microsoft Project 中处理工作项”，地址为：

http://msdn2.microsoft.com/en-us/library/ms244368(VS.80).aspx

Microsoft Excel 集成 安装 VSTS 或团队资源管理器应用程序会为 Microsoft Excel 提供扩展。对于涉及大量工作项的项 目，可以使用 Excel 集成功能，在 Excel 电子表格中创建工作项，然后将其上载工作项数据库，供 其他团队成员使用。 有关更多信息，请参见“在 Microsoft Excel 中处理工作项列表”，地址为： http://msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx

进度和报告 TFS 提供的报告会帮助您快速访问团队项目的状态、正在开发的软件的质量，以及以项目完成为目 标的进度。这些报告通过 TFS 数据仓库中维护的数据生成，汇总了得自工作项、源代码管理、测 试结果和生成的指标。 例如，您可以使用报告，根据团队的实际活动来查明您的团队一周又一周的工作速度。TFS 报告系 统的目标在于提供来自 VSTS 组件的集成数据，使项目经理和团队成员能够理解软件开发项目的状 态，并采取恰当的措施来确保其成功。 您用于创建团队项目的过程模板决定了有哪些报告默认可用，但也可以添加自己的自定义报告。由 过程模板创建的各报告的内容和用法在该模板的过程指南中得到了解释。Team Foundation Server 构 建于 Microsoft SQL Server™ 2005 之上，使用 SQL Server 来存储与工作项、质量属性、测试、测 试结果和生成结果相关的所有数据。TFS 随后使用 SQL Server Analysis Services 来聚集和分析数 据、驱动报告。过程模板创建的报告、由各团队成员使用 Microsoft Office Excel 或 Visual Studio 2005 报表设计器创建的报告均通过 SQL Server 2005 Reporting Services 和团队 SharePoint 门户站点变 为可用。 关于自定义报告的更多信息，请参见“如何：为 Visual Studio Team Foundation Server 创建自定义报 告”。

小结 Team Foundation Server 提供了项目管理功能，例如集中化工作项管理、过程管理、安全性和权限管 理、项目指标和报告，提升您在 Visual Studio 中管理开发项目的能力。 软件开发生命周期已经称为支持软件项目开发工作的工具的完整组成部分。TFS 提供了 MSF Agile 和 MSF CMMI 过程模板，它们支持两种截然不同的开发方法学。可以修改所提供的过程模板，或 从零开始创建您自己的过程模板，以满足团队的开发过程需求。

其他资源 z z z

关于使用 VSTS 进行软件项目管理的更多信息，请参见“Visual Studio 2005 Team System：软 件项目管理“，地址为：http://msdn2.microsoft.com/en-us/library/aa302181.aspx 关于使用 Microsoft Office Excel 完成项目管理任务的更多信息，请参见“在 Microsoft Excel 中 处理工作项列表”，地址为：http://msdn2.microsoft.com/en-us/library/ms181694(VS.80).aspx 关于使用 Microsoft Office Project 完成项目管理任务的更多信息，请参见“在 Microsoft Project 中处理工作项”，地址为：http://msdn2.microsoft.com/en-us/library/ms244368(VS.80).aspx

第 12 章 – 工作项简介 目标 z z z

了解工作项的目标和结构。 描述工作项工作流。 自定义工作项来满足您的团队的特定需求。

概述 这一章为您介绍了工作项，还解释了可以如何使用它们来帮助管理您的软件开发项目。每个工作项 都表示了要由您的开发团队执行的一个工作单元。在创建一个新的团队项目时，您选定的过程模板 中定义了一组工作项类型。 项目启动后，可以创建任何可用的工作项类型，跟踪工作。尽管默认工作项类型和行为是在过程模 板中定义的，但工作项类型的任何方面均可加以修改，以便更好地适应团队的工作方式。

如何使用本章 要从本章中获得最大收益，您应该： z z

阅读“工作项结构”一节，了解预定义工作项类型和工作项工作流的定义方法。 阅读“自定义工作项”一节，了解自定义工作项类型的方法和原因。

方案和解决方案 工作项是项目经理和团队主管跟踪项目中有待完成的工作以及已经完成的工作的首选方法。团队成 员使用工作项来跟踪其个人工作队列，并为彼此分配工作，例如，采用 bug 或任务的形式。 工作项在团队项目中的常见用途如下： z 为一个应用程序创建用户需求或服务质量 (QoS) 需求。 z 根据需求跟踪开发和测试。 z 创建开发任务，来表示为实现应用程序组件和功能而必须完成的工作。 z 创建 bug，表示应用程序组件和功能实现中的缺陷。 z 会审 bug 和任务，使之在整个团队中获得恰当的优先级和均衡。 z 跟踪开发任务，确定朝向代码完成状态的进展情况。 z 跟踪 bug 连同其他质量指标，确定应用程序的质量及其发布的准备情况。 如何使用工作项取决于为您的项目定义的工作项类型。工作项定义存储在您初次创建团队项目时选 定的过程模板中。可以在两种默认模板中选择一种——Microsoft® Solution Framework (MSF) for Agile Software Development (MSF Agile) 或 MSF for CMMI® Process Improvement (MSF CMMI)，也 可以自定义工作项来满足团队的具体需求和过程。

工作项结构 每种工作项类型均可定义如下： z

它有一种目的，有一种目标用途。例如，bug 用于跟踪质量缺陷、任务用于跟踪预定工作、QoS

z z

需求用于捕获关键的非功能方面，例如安全性和性能需求等等。 它有一个由状态和转换定义的工作流。例如，从“开放”到“已解决”到“关闭”状态的步骤。 有一个可设置、查询和报告的字段集。例如，优先级、状态和迭代。

工作项类型 MSF Agile 和 MSF CMMI 过程模板各自定义了一组工作项，映射到相应过程支那中定义的角色和 活动。

MSF Agile 工作项类型 MSF Agile 包含以下工作项类型： z z z z z

Bug。表示应用程序中的问题或潜在问题。 风险。表示会对项目产生负面影响的可能事件或条件。 方案。表示用户交互通过系统的单一路径。 任务。表示对一名团队成员完成某些工作的需求。 服务质量需求。表示制约系统应如何工作的需求。

MSF CMMI 工作项类型 MSF CMMI 包含以下工作项类型： z z z z z z z

Bug。表示应用程序中的问题或潜在问题。 变更请求。.表示对应用程序的建议更改。 问题。表示可能阻塞工作或当前正在阻塞工作的环境。 需求。表示应用程序应怎样解决客户问题的描述。 评审。表示代码、设计或部署评审的结果。 风险。表示会对项目产生负面影响的可能事件或条件。 任务。表示对一名团队成员完成某些工作的需求。

工作项工作流 每个工作项都有一个预定义的工作流，表示工作项应处于的各种状态，以及其间的转换。各状态均 自然与 TFS 中的一个角色关联。例如，测试人员在 MSF Agile 中打开一个新 bug 时，状态为活 动。一名开发人员修订了 bug 时，状态变更为已解决。测试人员验证了 bug 修订状态后，状态会 变为关闭。

工作流示例 以下示例展示了两种常见工作项类型的工作流。

MSF CMMI 任务 一个 MSF CMMI 任务具有以下几种可能的状态： z z z z

建议。例如，由开发人员、测试人员或架构师建议。 活动。例如，由一名主管或经理接受。 已解决。例如，已由开发人员解决。 已关闭。例如，已由测试人员测试并关闭。

图 12.1 展示了各种状态，以及状态间可能出现的转换。

建议

接受、调研

调研完成 活动

取消、完成不需要评审,， 延期、取缔

完成，需要 评审/测试

评审/测试 失败

拒绝

已解决 评审/测试 通过

出错关闭 重新激活

已关闭

图 12.1 MSF CMMI 的过渡状态

MSF Agile Bug 一个 MSF Agile Bug 具有以下几种可能的状态： z z z

活动。例如，由一名测试人员打开。 已解决。例如，已由开发人员解决。 已关闭。例如，已由测试人员测试并关闭。

图 12.2 展示了各种状态，以及状态间可能出现的转换。 活动 已修订、 按设计、 延期、 复制、 作废、 无法重生成

已解决

回归、 重激活

已修订、 按设计、 延期、 复制、 作废、 无法重生成

已关闭

图 12.2 MSF Agile 的过渡状态

决议被拒绝、 错误的修订、 测试失败 延期、 作废、 无法重生成、按设计、 复制、 已修订

自定义工作项 在有些情况下，您可能希望修改 MSF Agile 或 MSF CMMI 中定义的工作项类型： z z z

工作项缺失了一个对您的开发过程至关重要的字段。 工作项工作流不匹配团队的工作方式。 您需要一种新工作项类型。

要为这些情况提供支持，可以在 TFS 中进行以下操作： z z z

添加/删除工作项类型。 修改现有工作项中的字段。 修改现有工作项中的状态和转换。

关于自定义工作项的更多信息，请参见“如何：在 Visual Studio Team Foundation Server 中自定 义过程模板”。

小结 项目经理和团队主管使用工作项来跟踪项目中有待完成的工作。它们用于创建开发任务来表示必须 完成的工作、创建 bug 来表示实现中的缺陷，并创建用户需求或服务质量 (QoS) 需求。除此之外， 它们还可用于按照需求跟踪开发和测试，并确定应用程序的质量及其发布准备情况。 MSF Agile 和 MSF CMMI 过程模板提供了一组默认工作项类型。可以自定义这些类型，或创建新 工作项类型，来满足您的过程需求。

其他资源 z z z

关于工作项的更多信息，请参见“管理 Team Foundation 工作项“，地址为： http://msdn2.microsoft.com/en-us/library/ms181314(VS.80).aspx 要下载 MSF CMMI 过程模板并查看可用工作项类型，请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=12A8D806-BB98-4EB4-BF6B-FB5B2 66171EB&displaylang=en 要下载 MSF Agile 过程模板并查看可用工作项类型，请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=EA75784E-3A3F-48FB-824E-828BF5 93C34D&displaylang=en

第 VI 部分 过程模板 本节内容： ¾ 过程模板简介 ¾ MSF for Agile Software Development 项目

第 13 章 – 过程模板简介 目标 z z z

理解过程模板的目的、内容和结构。 了解 Microsoft® Solution Framework (MSF) for Agile Software Development (MSF Agile) 和 MSF for CMMI® Process Improvements (MSF CMMI) 过程模板间的重要差异。 自定义过程模板来满足团队的特定需求。

概述 这一章解释了过程模板在 Microsoft Visual Studio® 2005 Team Foundation Server (TFS) 中的角色。辨 认了附带的两种过程模板的主要功能和主要差异：MSF Agile 和 MSF CMMI。 软件开发过程非常复杂，涉及多层次的相互依赖活动。这些过程以文档的形式对开发团队可用，但 通常不会由工具实施。这种工具支持的缺乏使开发团队难以一致地学习和遵从过程。项目经理可使 用多种多样的工具进行项目管理、需求管理、bug 跟踪或评审管理，它们往往未得到很好的集成。 这样的缺乏集成使跨多个项目实施一致的方法学、生成一致的报告使公共团队理解项目进度和健康 情况更加困难。一致性的缺乏可使服务器产生不可靠的过程分析，从而使长期识别和实现过程改进 的难度进一步提高。 Visual Studio Team System (VSTS) 和 TFS 提供了一种集成化环境，支持一个软件开发项目中涉及 的大多数过程活动。TFS 通过使用过程模板实现其生命周期方法学。一个过程模板就是一组可扩展 标记语言 (XML) 文件，为构成开发方法学的过程和工件提供规范。这一章解释了过程模板的体系 结构及其组件，使您能够更好地理解如何利用和自定义已提供的过程模板。 如果现有过程模板不能很好地匹配团队的开发过程，可以创建新过程模板、修改现有模板或选择 Microsoft 合作伙伴提供的过程模板。要查看 Microsoft 合作伙伴提供的过程模板，请参见： http://msdn2.microsoft.com/en-us/teamsystem/aa718801

如何使用本章 使用这一章来理解过程模板体系结构、结构和自定义。要从本章中获得最大收益，您应该： z z

阅读“MSF Agile 和 MSF CMMI 过程模板”一节。了解默认过程模板以及如何选择最适合团 队需求的模板。 阅读“自定义过程指南”一节。了解如何自定义现有过程模板，更好地满足团队的需求。

MSF Agile 和 MSF CMMI 过程模板 Team Foundation Server 附带两个过程模板：MSF Agile 和 MSF CMMI。这两个过程模板针对两种 不同类型的软件开发。如果您正在使用一种敏捷方法学来生成软件，应使用 MSF Agile。MSF Agile 鼓励测试驱动的开发和其他敏捷实践。如果您采用的是 Software Engineering Institute (SEI) Capability Maturity Model® Integration 方法学，则应使用 MSF CMMI。.这是一个以改进现有开发过程为目标 的正式过程。 模板的不同在于其提供的内容。例如，它们创建不同类型的默认报告和工作项类型。这些模板可以 轻而易举地进行编辑，来适应您的项目的需求。

自定义过程指南 您所创建的项目可能不适合使用 VSTS 提供的过程模板。您可能需要另外一种不同的工作项类型， 或使用完全不同的过程方法学。例如，如果您正使用 SCRUM，当前过程模板中未提及任何 sprint。 在这种情况下，您需要修正或替换现有过程模板，适应您的团队所使用的方法学。

过程模板体系结构 过程模板体系结构中有三个主要片段： z z z

过程模板插件 XML 过程定义文件 新建团队项目向导

过程模板插件 过程模板插件是在新团队项目创建时运行的组件。插件为模板的特定区域设置所需文件并配置数据。 以下插件随 TFS 开箱即用。 z z z z z z

分类 – 定义团队项目的初始迭代和区域。 组和权限 – 定义团队项目的初始安全组及其权限。 Windows SharePoint 服务 – 基于 Microsoft Windows SharePoint® 站点模板为团队定义项目 门户。它还定义了模板文件和过程指南。 工作项跟踪 – 定义团队项目的初始工作项类型、查询和工作项实例。 报告 – 定义团队项目的初始报告并设置报告站点。 版本控制 –定义团队项目的初始版本控制安全性权限和签入说明。

您可修改各插件定义文件，来自定义一个过程模板。除分类插件外，还可以删除插件定义文件来自 定义一个过程模板。

XML 过程定义文件 XML 过程定义文件是一组 XML 文件，定义了一组任务，为正确配置过程的新团队项目，这组任 务必须运行。使用“新建团队项目向导”创建团队项目时，它会运行所需插件。各插件均会读取其 对应 XML 过程定义文件，获取必须运行的任务列表。通过使用 XML 过程定义文件，您就可以指 定插件必须实现哪些配置和设置。下面是关于 XML 文件的细节： z

z

z

工作项跟踪 XML – 此过程定义文件名为 Workitems.xml，位于过程模板文件夹层次结构的工 作项跟踪文件夹中。有三种重要类型的任务需要指定：工作项类型、工作项查询和工作项实例。 工作项类型 – 为将在团队项目上跟踪的工作项（例如任务、bug 和需求）定义规则、字段、 状态和转换。 工作项查询 – 用于找到工作项的特定分组，例如任务或活动 bug。工作项查询在过程模板 文件夹层次结构的工作项文件夹内的工作项查询 (WIQ) 文件中指定。 工作项实例 – 在创建团队项目时默认创建的工作项实例初始集。 分类 XML – 此过程定义文件名为 Classification.xml，位于过程模板文件夹层次结构的分类文 件夹中。它包含两个部分：迭代和区域。 迭代 – 用于定义团队应重复一组主要活动多少次，例如计划、开发、测试。迭代影响工作 项查询和报告，因为迭代用于组织工作项。 区域 – 用于组织团队项目中的工作。例如，一个团队可能根据产品或功能组织工作，例如 UI 区域、应用程序区域和数据库区域。区域用于为查询和报告组织工作项。 Windows SharePoint 服务 XML – 此过程定义文件名为 WssTasks.xml，位于过程模板文件夹 层次结构的 Windows SharePoint 服务文件夹中。有三种关键的任务需要指定：站点模板（要使 用哪种站点模板）、文档模板库（要创建哪些文档库）和文件夹和文件（将哪些文件夹和文件

z

z

z

复制到文档库中）。 站点模板 – 必须指定一个站点模板，项目门户将基于此模板。该站点模板还必须在 TFS SharePoint 门户上可用。站点模板未包含在过程模板中。 文档库 – 项目门户被创建后，可以指定要创建的其他文档库。 文件夹和文件 – 项目门户被创建后，可以指定要创建的其他文件夹。还可以指定要复制的 文件，例如模板文件。 版本控制 XML – 此过程定义文件名为 VersionControl.xml，位于过程模板文件夹层次结构的版 本控制文件夹中。它定义了团队项目的初始版本控制安全性权限、签入说明，以及是否需要互 斥签出。 签入说明 – 指定是否要包含签入说明。签入说明由开发人员在代码签入时提供，描述代码 更改如何或是否关联到团队过程。例如，签入说明可指出变更是否是安全性评审的一部分， 还可包含与安全性评审相关的变更的细节。 互斥签出 – 用于控制多个用户是否可以同时签出一个文件。 权限 – 定义安全组和个人可以在版本控制下对项执行哪些操作。 报告 XML – 此过程定义文件名为 ReportsTasks.xml，位于过程模板文件夹层次结构的报告文 件夹中。它定义了团队项目的初始报告。 报告站点 – 报告站点在项目门户主页上有一个标签为报告的链接。 文件夹 – 可以在报告站点上创建文件夹。您创建的文件夹会出现在项目站点上和“团队资 源管理器”的报告文件夹中。 报告 – 用于通过使用 .rdl 文件来添加报告 组和权限 XML – 此过程定义文件名为 GroupsandPermissions.xml，位于过程模板文件夹层次结 果的租和权限文件夹中。用于定义项目的初始安全组。 组 – 用于指定一个新的 TFS 安全组。 权限 – 用于为您指定的各组定义权限。

新建团队项目向导 使用“新建团队项目向导”来创建新团队项目。该向导使用插件和 XML 过程定义文件来创建项目。

自定义方法 要自定义一个过程模板，请按以下步骤操作： 1.

2.

3.

4.

5.

评审 TFS 提供的过程模板，选择最符合组织过程的一种。 下载所选过程模板。 自定义过程模板的各种组件。 将自定义模板上载到 TFS。 验证更改适合您的过程需求。

这种核心方法作为以下解决方案的一部分使用，用于自定义过程模板：

z

手动自定义 XML 文件。手动自定义易于出错，但提供了过程模板自定义的细粒度控制。有关 更多信息，请参见“自定义过程模板”，地址为：

http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx z

随 Power Tool 提供的过程模板编辑器工具。Visual Studio 2005 Team Foundation Server Power Tool 的最新版本——一组增强、工具和命令行实用工具，可改进 TFS 体验——提供了一种查 看和自定义过程模板的图形化工具。连接到 TFS 时，可以使用这种工具来自定义活动项目上 的工作项类型定义和全局列表。有关更多信息，请参见“如何：在 Visual Studio Team Foundation Server 中自定义过程模板”。

公共自定义 下面描述了一组组件，您通常会对这些组件进行自定义，以创建您自己的自定义过程：

z

z

z

z

z

z z

组和权限。这个开箱即用的过程模板有一组分配了不同权限的组。如果与这些模板关联的默认 组和权限不足以或不适合满足您的过程需求，可以升级这些组或创建新组。还可以将单独的用 户添加到组中、从组中删除用户、授予或收回一个组的权限。 源代码管理签入说明和策略。这个开箱即用的过程模板有一组源代码管理签入说明和策略。如 果默认的浅说说明不足以或不适合满足您的过程需求，可以添加或删除签入说明自动、使某些 字段成为必要字段，而其他字段不是。如果默认的签入策略不足以或不适合，可以添加、更新 或删除各签入策略。 区域和迭代。这个开箱即用的过程模板未提供区域或迭代的分类结构。您可以根据自己的具体 过程需求，自定义区域和迭代。推荐的方法是根据项目的组件或功能开拓区域。迭代可以是基 于时间的周期，可利用它重复一组特殊的主要活动，例如计划、开发和测试。 团队门户。这个开箱即用的过程模板提供了一个默认团队门户，它可以成为团队成员间及与组 织中其他人员通信的中枢。您可以修改团队门户来更改其外观、行为和内容，满足您的过程需 求。 过程指南。这个开箱即用的过程模板提供了相关的过程指南，解释了团队项目中所用的角色、 表单、报告和工作流。自定义过程模板满足需求时，您必须编辑过程指南，反映对各组件的更 改。 报告。这个开箱即用的过程模板提供了一组默认报告。如果默认报告不适合或不足够，可以根 据您的需求，创建您自己的自定义报告。 工作项类型和查询。这个开箱即用的过程模板具有一组工作项类型、默认工作项实例和查询。 如果默认工作项类型、工作项实例和查询不足以或不适合满足您的过程需求，可以自定义工作 项类型来适应您的工作流，或自定义您希望跟踪的不同类型的工作项。例如，可以：

添加新工作项类型。 删除现有工作项类型。 添加默认工作项类型实例。 删除默认工作项类型实例。 创建自己的公共或私有查询。

还可以修改现有工作项类型，例如：

添加字段。 重命名字段。 限制字段允许值的列表。 更改状态和受支持的状态转换。 使字段成为必要字段或只读字段。 使一个字段依赖于另一个字段。 自动填充字段值。 重新安排表单上的信息外观。 将 Microsoft Office Project 列更改为特定字段映射的列。

自定义过程的工作原理是什么？ 自定义一个过程模板涉及以下步骤： 1.

2.

用户启动“新建团队项目向导”。 向导要求用户输入： z 团队项目的名称。 z 创建团队项目时要使用的过程模板。 向导中显示的屏幕由所用插件决定。例如，如果一个过程模板未包含 Windows SharePoint 服务 插件，就不会出现任何屏幕要求用户输入关于项目门户的信息。

3.

4.

用户提供了向导请求的信息并单击“完成”后，向导会调用插件来执行创建团队项目的工作。 插件的调用顺序由 XML 过程定义文件决定。 向导读取过程模板中包含的指令，然后创建并配置特定项。 用户不需要指定要创建的各种工作项类型的细节，因为指令已由过程模板提供。

注意：如果向导在创建新团队项目时遇到问题，您将看到一条错误消息，描述该问题并给出更正操 作建议。

小结 如果您正在使用一种敏捷方法学来生成软件，应使用 MSF Agile。如果您采用的是 Software Engineering Institute (SEI) Capability Maturity Model® Integration 方法学，则应使用 MSF CMMI。. 过程模板体系结构的关键组件是过程模板插件、XML 过程定义文件和“新建团队项目向导”。 如果默认的过程模板不能满足您的过程需求，可以通过手动自定义 XML 过程定义文件来自定义模 板，也可使用过程编辑器工具来自定义过程模板。 自定义最常用的区域是组和权限、源代码管理签入说明和策略、报告以及工作项类型定义。

其他资源 z z z z z z

关于选择过程模板的更多信息，请参见“选择过程模板”，地址为： http://msdn2.microsoft.com/en-us/library/ms400752(vs.80).aspx 要下载 MSF CMMI 过程模板，请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=12A8D806-BB98-4EB4-BF6B-FB5B2 66171EB&displaylang=en 要下载 MSF Agile 过程模板，请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=EA75784E-3A3F-48FB-824E-8 28BF593C34D&displaylang=en 过于过程模板自定义的更多信息，请参见“过程模板自定义概述”，地址为： http://msdn2.microsoft.com/en-us/library/ms194945(VS.80).aspx 要下载包含过程模板编辑器的 Team Foundation Server Power Tools，请访问： http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx 要查看 Microsoft 合作伙伴提供的过程模板，请参见： http://msdn2.microsoft.com/en-us/teamsystem/aa718801

第 14 章 - MSF for Agile Software Development 项目 目标 z z z

了解何时使用 Microsoft® Solution Framework (MSF) for Agile Software Development (MSF Agile) 过程模板。 识别团队使用 MSF Agile 过程模板的典型方式。 自定义 MSF Agile 过程模板以满足您团队的具体需求。

概述 MSF Agile 过程模板定义的过程整合了来自敏捷开发运动的关键理念以及来自 MSF 的原则与实 践。此过程支持一种使用多次迭代和应用程序生成的基于方案的方法的敏捷软件工程策略。模板提 供了支持团队开发所必须的自动化和指南，包括配置管理、项目管理、工作项跟踪和一个用于通信 的项目门户。 本章解释了一个典型 MSF Agile 软件开发项目的工作流，展示了使用 MSF Agile 过程的团队示例， 还描述了默认模板设置以及附带的模板中需要自定义的选项。

如何使用本章 如果您希望更好地理解 MSF Agile 过程模板和过程指南是如何工作的以及它已经怎样地得到了各 种团队的成功应用，请阅读这一章。要从本章中获得最大收益，您应该： z z z

阅读“MSF for Agile Software Development 默认设置”一节。了解 MSF Agile 过程模板的细 节，包括默认报告、工作项和权限。 详读“MSF for Agile Software Development 实例”一节。了解实际团队已经怎样成功地应用了 MSF Agile 来开发和发布应用程序。 阅读“第 13 章：过程模板简介”。如果希望从整体上进一步了解过程模板，请阅读“第 13 章： 过程模板简介”。

MSF for Agile Software Development 的工作流 MSF Agile 过程模板定义了一组任务，这些任务在迭代期间要由软件中涉及的各种角色执行，包括 业务分析人员、架构师、项目经理、开发人员和测试人员。图 14.1 展示了与所定义的各任务相关 联的关键活动。 任务 创建项目待办事项 创建解决方案体系结构

创建客户使用方案

创建服务质量需求

关键活动 捕获项目远景 创建体系结构原型 确定接口 创建基础结构 差分方案 将方案捕获到 TFS 中 划分方案列表优先级 识别安全性目标 识别性能目标 在 TFS 中捕获需求

迭代计划

迭代开发

迭代测试

迭代过程评审

划分需求优先级 将方案和需求划分成开发和测试任务 为开发和测试任务创建预测 分配开发和测试任务以及安排时间 为开发任务编写代码 为开发任务创建/更新单元测试 运行单元测试并执行代码分析 为测试任务编写验证测试 运行测试用例并执行探索性测试 为已发现的问题开放 bug 为迭代评估任务进度 会审迭代中识别出的 bug 评估测试指标阈值

图 14.1 MSF Agile 任务与关键活动

MSF for Agile Software Development 默认设置 通过使用 MSF Agile 过程模板创建新团队项目时，Microsoft Visual Studio® 的主窗口中会显示一个 概念页面，列举过程指南。这是您对 MSF Agile 过程的初始视点。还可通过项目门户主页访问此信 息。 工具的配置已经超出了过程的描述范围，包括工作项（例如方案、服务质量需求、任务、bug 和风 险）、项目报告、角色（组和权限）以及项目门户。MSF Agile 模板提供的关键项包括： z z z z z z

工作项 组和权限 源代码管理 区域和迭代 报告 门户

以下几节详述了使用 MSF Agile 过程模板时可用的重要默认项。

工作项 MSF Agile 过程模板包含以下工作项类型： z z z z z

Bug。表示应用程序中的问题或潜在问题。 风险。表示会对项目产生负面影响的可能事件或条件。 方案。表示用户交互通过您所生成的系统的单一路径。 任务。识别团队程序需执行的特定工作项。 服务质量需求。表示非功能性需求，例如安全性、性能或可管理型需求。

根据 MSF Agile 过程模板创建新团队项目时，会为您创建以下工作项。这提供了在项目启动时需要 执行的公共任务集，从而节省了您的工作。 z z

设置：设置权限。此任务的目的在于将团队成员添加到四个安全组之一。生成服务、项目管理 员、贡献者或读者。 设置：源代码迁移。此任务的目的在于迁移 Microsoft Visual SourceSafe® 中的现有源代码—— 如果您正在将一个现有项目迁移到 Microsoft Visual Studio Team Foundation Server (TFS)。应在 为团队成员授予团队项目访问权限之前完成源代码迁移。

z

z z z z z z z z

z z z z

设置：工作项迁移。如果您正在将一个现有项目移入 TFS，那么可以将 bug 和任务之类的工 作项从 Clearquest 或逗号分隔值 (CSV) 文件迁移出来。应在为团队成员授予团队项目访问权 限之前完成工作项迁移。 设置：设置签入策略。此任务的目的在于设置围绕源代码签入的业务规则或策略。 设置：配置生成。此任务的目的在于创建初始源代码树，并将生成设置为定期运行（通常是每 日）。 设置：为安装并启动向用户发送邮件。此任务的目的在于向提供关于应连接哪个 TFS 、应使 用哪个团队项目开始在团队项目上工作的信息的团队成员发送电子邮件 创建远景陈述。此任务的目的在于为项目创建一个远景陈述——项目目标结果的视图，由项目 的所有利益相关人共享。 设置：在团队项目门户上创建项目描述。此任务的目的在于更改默认项目描述，更好地描述项 目的目的、目标或远景。 创建角色。此任务的目的在于创建表示与系统交互的用户的角色。在思考应用程序设计时，可 以使用角色，因为他们是系统的目标用户。 定义迭代长度。此任务的目的在于定义项目将使用的迭代周期。这取决于项目的规模和复杂度。 创建包含测试阈值的测试方法工作表。此任务的目的在于在项目迭代的早期很好地理解测试策 略。理解测试方法能帮助您更以有效地安排测试任务，并将允许您的开发人员在测试考虑事项 的指导下进行实现。 头脑风暴和划分方案列表优先级。此任务的目的在于识别关键使用方案，并为其设置优先级。 头脑风暴和划分服务质量需求列表优先级。此任务的目的在于识别非功能性 QoS 需求，例如 安全性、性能和可管理性方案。 设置：创建项目结构。此任务的目的在于创建项目结构，捕获开发团队应在其中工作的区域。 创建迭代计划。此任务的目的在于决定如何将开发工作划分成迭代。

报告 默认情况下，以下报告随 MSF Agile 过程模板提供： z z z z z z z z z z z z z z z

Bug 优先级。是否发现了正确的 bug？此报告展示了所发现的高优先级 bug 与低优先级 bug 的比率。 Bug 率。发现、修订和关闭 bug 的效率多高？此图表展示了一段时间以来的新 bug、bug 待 办事项和 bug 解决的趋势。 生成。生成的质量如何？这份报告提供了可用生成的列表，包括生成质量和其他详细信息。 项目速度。团队完成工作的速度如何？这份报告展示了团队完成计划工作的速度，还显示了每 天的变更速率。 质量指标。软件质量如何？这份报告将测试结果、bug、代码覆盖和代码改动收集到一份报告中， 以便跟踪项目的健康情况。 负载测试总结。这份报告展示了应用程序负载测试的测试结果。 回归。这份报告展示了之前顺利通过且现在失败的全部测试列表。 重新激活。有多少工作项被重新激活？这份报告展示了被过早解决或关闭的工作项。 相关工作项。哪些工作项依赖于其他工作项？这份报告展示了与其他工作项相链接的工作项列 表，以便跟踪依赖项。 剩余工作。还有多少工作有待完成？这些工作将在何时完成？这份报告展示了一段时间以来剩 余、已解决和已关闭的工作。计划剩余工作的未来趋势使您能够预测代码完成的时间点。 计划外任务。存在多少计划外任务？这份报告展示了总体工作与剩余工作的对比，并将计划中 活动与计划外活动区分开来。 会审。有哪些工作项需要会审？这份报告展示了依然处于建议状态的所有工作项。 工作项。活动工作项有哪些？这份报告列举了所有活动工作项。 工作项所有者。为团队中的每位成员分配多少工作？这份报告显示每位团队成员的工作项。 工作项状态。存在多少活动、已解决和已关闭的工作项？这份报告列举了所有活动、已解决和 已关闭的工作项。

组和权限 默认情况下，以下组在 MSF Agile 过程模板中可用： z z z z

读者。该组的成员拥有团队项目的只读访问权限。 贡献者。该组成员可以在团队项目内添加、修改和删除项。 生成服务。该组的成员拥有团队项目的生成服务权限。该组仅用于服务账户。 项目管理员。该组的成员可以在团队项目中执行所有操作。

源代码管理 MSF Agile 使用以下默认源代码管理设置： z z

多次签出。默认情况下，MSF Agile 允许多次签出，这使多个团队成员能够同时处理同一个文 件。所导致的任何冲突都必须在签入时解决。 权限。源代码管理的默认权限如下： 项目管理员。具有全部可用权力。 生成服务。具有读取、挂起更改、签入、标记、启动生成和编辑生成的权力。 贡献者。具有读取、挂起更改、签入、签出、标记和启动生成的权力。 读者。仅有对源代码管理的只读访问权限。

区域和迭代 开箱即用的 MSF Agile 过程模板未提供区域或迭代的分类结构。推荐的方法是根据项目的组件或功 能开拓区域。迭代可以是基于时间的周期，可利用它重复一组特殊的主要活动，例如计划、开发和 测试。

MSF for Agile Software Development 实例 以下示例展示了 MSF for Agile Software Development 过程如何被 Microsoft 内部的模式与实践团 队和 Microsoft 外部团队采纳和使用。

示例 1：模式与实践团队 以下示例展示了一个典型的模式与实践项目是如何通过使用 MSF Agile 过程执行的。

通过迭代 0 的新项目 z

z

产品经理： 1. 与客户和利益相关人交互，收集项目需求。这些需求会被捕获到一个名为 Project Back Log 的 Microsoft Office Word 文档中。 2. 通过使用 Microsoft Office PowerPoint® 为项目创建一个远景陈述。 3. 与客户和各方利益相关人开展头脑风暴，并定义将应对项目的需求和远景的方案。 4. 与项目经理和其他利益相关人协力工作，划分方案优先级。 项目经理： 1. 在 TFS 中将方案作为工作项捕捉。 2. 根据项目规模、交付功能确定迭代周期持续时间。

迭代前计划 z z

项目经理根据方案优先级确定哪些方案应在迭代过程中工作。 产品经理与项目经理协作，为方案创建服务质量 (QoS) 需求。QoS 随后链接到方案。

迭代计划 z

z z

项目经理： 1. 开发人员与其他团队成员协作，将方案拆分成开发任务。 2. 在 TFS 中捕获开发任务，并将其链接到方案。 3. 为各开发任务定义验收标准。 4. 将 QoS 需求拆分成测试任务。 5. 在 TFS 中捕获测试任务，并将其链接到 QoS。 6. 为各测试任务定义验收标准。 7. 分配任务并为其安排时间。 开发人员预测各开发任务。 重点：如果（在开发人员一方）任务似乎多用了一两天时间来实现，则应将其差分成子部分。 测试人员为各测试任务提供预测。

在迭代过程中 z z z

项目经理指导迭代。 开发人员为开发任务编写代码，随后在验收标准达到后关闭任务。 测试人员执行分配给自己的测试任务，然后为所发现的任何问题创建新 bug（工作项）。

迭代后 z

z

项目经理： 1. 评估项目进度，重新划分当前迭代中未完成方案的优先级。 2. 为利益相关人提供状态报告。 3. 根据方案优先级确定哪些方案应在再一次迭代过程中工作。 产品经理： 1. 添加任何新发现的方案。 2. 重新划分方案的优先级（如有必要）。 3. 与项目经理协作，为项目创建 QoS 需求。QoS 随后链接到方案。

示例 2：客户现场聘请 以下示例展示了 MSF Agile 过程如何为客户现场聘请所用。

通过迭代 0 的新项目 z

业务分析人员： 1. 创建一份简短（一页）的远景陈述。 2. 确定一位可提供输入的现场客户，并为系统创建角色。 3. 与客户就方案（只是举个例子）开展头脑风暴。 4. 与客户一起划分方案的优先级。 5. 为下次迭代编写方案。

z

项目经理： 1. 将开发人员聚集在一起，获得其预测。这些预测是粗粒度的预计。 2. 检查优先级是否因成本而发生了变化。 3. 为方案的下次迭代安排时间。

z z

z

架构师将方案拆分为体系结构任务。 开发人员： 1. 将方案划分成开发任务。 2. 定义恰当的生成策略（如有可能，采用连续的集成）。 测试人员将方案划分成测试任务。

在迭代过程中 z

项目经理： 1. 指导迭代。 2. 指导项目。

z z z

架构师定义解决方案体系结构。 开发人员实现开发任务。 测试人员测试方案。

迭代 0 之后 任务在此时略有变化。 z

业务分析人员： 1. 更新角色（如有必要）。 2. 添加任何新发现的方案。 3. 重新划分方案的优先级（如有必要）。 4. 为下次迭代编写方案。

z

项目经理： 1. 预测任何新方案。 2. 为方案的下次迭代安排时间。

z z

架构师将方案拆分为体系结构任务。 开发人员： 1. 将方案划分成开发任务。 2. 更新生成过程（如有可能，使用连续的集成）。

z

测试人员将方案划分成测试任务。

自定义 MSF Agile 过程模板 可以使用两种方法来自定义 MSF Agile 过程模板，使之适合您的特定组织需求。 z

z

手动自定义 XML 文件。手动自定义易于出错，但提供了过程模板自定义的细粒度控制。有关 更多信息，请参见“自定义过程模板”，地址为： http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx, 过程模板编辑器。Visual Studio 2005 Team Foundation Server Power Tool 的新版本——一组增 强、工具和命令行使用工具，可以改进 TFS 体验——提供了一种基于用户界面的工具，可用于 查看和自定义过程模板。连接到 TFS 时，可以使用这种工具来自定义活动项目上的工作项类 型定义和全局列表。有关更多信息，请参见“如何：在 Visual Studio Team Foundation Server 中自定义过程模板”。

小结 MSF Agile 过程模板定义了一组任务，这些任务要由软件开发生命周期中涉及的各种角色执行。MSF Agile 过程模板定义了工作项、组和权限、源代码管理、区域和迭代、报告和团队门户，以支持敏 捷过程。 如果默认过程模板不能满足您的过程需求，可以手动自定义 XML 过程定义文件或使用 TFS Power Tools 附带的过程编辑器工具，从而自定义模板。

其他资源 z z z z

要下载 MSF Agile 过程模板，请访问： http://www.microsoft.com/downloads/details.aspx?FamilyID=EA75784E-3A3F-48FB-824E-8 28BF593C34D&displaylang=en 要下载包含过程模板编辑器的 Team Foundation Server Power Tools，请访问： http://msdn2.microsoft.com/en-us/vstudio/aa718351.aspx 过于过程模板自定义的更多信息，请参见“过程模板自定义概述”，地址为： http://msdn2.microsoft.com/en-us/library/ms194945(VS.80).aspx 关于手动自定义过程模板的更多信息，请参见“自定义过程模板”，地址为： http://msdn2.microsoft.com/en-us/library/ms243782(VS.80).aspx

第 VII 部分 报告 本节内容： ¾ 报告简介

第 15 章 – 报告简介 目标 z z z z z

描述 Microsoft® Visual Studio® Team Foundation Server (TFS) 报告体系结构。 识别构成 TFS 报告的组件。 描述各可用报告的用途。 了解哪种过程模板包含哪种报告。 自定义和新建报告。

概述 本章描述了 TFS 报告体系结构，还介绍了可随新团队项目一起使用的公共报告。本章中还将公共 报告方案与 TFS 中可用的报告联系起来，描述了自定义现有报告会新建报告的常见原因。TFS 报 告使您能够查看关于团队项目许多方面的聚合数据。可以使用这种信息来分析项目进度、项目健康 情况和开发与测试团队的有效性。 TFS 报告使用了 Microsoft SQL Server™ 2005 报表服务来创建、管理和运行报告。每个过程模板都 包含一组预定义的报告，在项目创建时，这些报告会部署到项目的报告文件夹中。通过使用报表服 务，还可以修正这些报告，并为项目创建自定义报告。可以向现有过程模板添加新报告，使之可供 其他团队项目使用。

如何使用本章 使用这一章来理解 TFS 报告的工作原理，以及它能够怎样帮助您评估项目健康情况和状态。要从 本章中获得最大收益，您应该： z z z z

阅读“方案和解决方案”一节。理解使用 TFS 报告的常见原因，掌握各标准报告的用途。 阅读“物理体系结构”一节。了解哪些组件构成了报告系统，以及它们是如何彼此联系在一起 的。 阅读“自定义报告”一节。了解可用于自定义和创建报告的机制。 阅读附带的“如何”文章。阅读以下附带的“如何”文章，获得本章所述各种步骤的详尽演练。 y 如何：使用 Visual Studio 2005 Team Foundation Server 自定义报告 y 如何：在 Visual Studio 2005 Team Foundation Server 中创建自定义报告 y 如何：使用 Visual Studio 2005 Team Foundation Server 创建长期风险报告

方案和解决方案 报告是项目经理和团队主管了解当前项目最新信息的主要手段。新建了一个团队项目之后，会根据 您选择的过程模板生成一组报告。这些报告可通过项目的 Microsoft Office SharePoint® 门户站点使 用，也可以通过 Visual Studio 内“团队资源管理器”中的报告节点使用。 下面是可以使用 TFS 报告解答的常见问题： z z z z z z

应用程序将在何时准备好发布？ 工作是否按计划进行？ 生成质量如何？ 根据定义的方案，开发状态如何？ 开发工作完成的速度如何？ Bug 是否得到了修订？

z

Bug 是否回归？

Team Foundation Server 报告 Microsoft Solution Framework (MSF) for Agile Software Development (MSF Agile) 和 MSF for CMMI® Process Improvement (MSF CMMI) 过程模板均包含一组默认报告。

Bug 过程模板中与 bug 相关的报告使您能够查看生成和修订的是哪种类型的 bug，并识别趋势。以下与 bug 相关的报告可用： z z

Bug 优先级。是否发现了正确的 bug？此报告展示了所发现的高优先级 bug 与低优先级 bug 的比率。此报告在所提供的两种过程模板中均可用。 Bug 率。发现、修订和关闭 bug 的效率多高？此报告展示了一段时间以来的新 bug、bug 待 办事项和 bug 解决的趋势。此报告在所提供的两种过程模板中均可用。

发布管理 发布管理报告使您能够判断您的软件有多么接近适合发布的软件。以下发布管理报告可用： z z z z z

实际质量与计划速度的对比。在质量不可接受之前，可以完成多少方案？此报告展示了各迭代 的关系，从预计规模到整体质量。此报告在两种过程模板中均可用。 生成。生成的质量如何？这份报告提供了可用生成的列表，包括生成质量和其他详细信息。这 份报告在 MSF for CMMI Process Improvement 中可用。 质量指标。软件质量如何？这份报告将测试结果、bug、代码覆盖和代码改动收集到一份报告中， 以便跟踪项目的健康情况。这份报告在 MSF Agile 和 MSF CMMI 中均可用。 速度。团队完成工作的速度如何？这份报告展示了团队完成计划工作的速度，还显示了每天的 变更速率。这份报告在 MSF Agile 和 MSF CMMI 中可用。 方案细节。我们根据哪些方案生成了应用程序？这份报告提供了各方案的信息，包括完成状态、 风险和测试进度。这份报告在 MSF CMMI 中可用。

测试 测试报告使您能够监视测试有效性和进度。以下测试报告可用： z z z z z

回归。哪些测试一度顺利通过但现在失败了？这份报告展示了之前顺利通过且现在失败的全部 测试列表。这份报告在 MSF CMMI 中可用。 需求测试历史。方案和需求得到了多好的测试？这份报告展示了对已定义方案和需求的测试进 度。这份报告在 MSF CMMI 中可用。 无活动 bug 的测试失败。是否有跟踪所有已知缺陷的 bug？这份报告展示了已失败且未与任 何 Open bug 相关联的所有测试。这份报告在 MSF CMMI 中可用。 有 Open Bug 的测试通过。Bug 列表是否最新且与应用程序质量一致？这份报告展示了现已 通过的测试的旧 bug。这份报告在 MSF CMMI 中可用。 负载测试总结。对应用程序性能的负载测试结果如何？这份报告展示了应用程序负载测试的测 试结果。这份报告在 MSF Agile 中可用。

工作项 工作项报告使您能够评估项目的当前状态和当前项目进度。以下工作项报告可用： z z

开放的问题和阻塞的工作项趋势。尚存多少开放的问题？这份报告展示了剩余的开放问题及其 解决趋势。这份报告在 MSF CMMI 中可用。 重新激活。有多少工作项被重新激活？这份报告展示了被过早解决或关闭的工作项。这份报告

z z

z z z z z

在 MSF Agile 和 MSF CMMI 中可用。 相关工作项。哪些工作项依赖于工作项？这份报告展示了与其他工作项相链接的工作项列表， 以便跟踪依赖项。这份报告在 MSF CMMI 中可用。 剩余工作。还有多少工作有待完成？这些工作将在何时完成？这份报告展示了长时间以来剩余、 已解决和已关闭的工作。计划剩余工作的未来趋势使您能够预测代码完成的时间点。这份报告 在 MSF Agile 和 MSF CMMI 中可用。 会审。有哪些工作项需要会审？这份报告展示了依然处于建议状态的所有工作项。这份报告在 MSF CMMI 中可用。 计划外任务。存在多少计划外任务？这份报告展示了总体工作与剩余工作的对比，并将计划中 任务与计划外任务区分开来。这份报告在 MSF Agile 和 MSF CMMI 中可用。 工作项。活动工作项有哪些？这份报告列举了所有活动工作项。这份报告在 MSF CMMI 中可 用。 工作项所有者。为团队中的每位成员分配多少工作？这份报告显示每位团队成员的工作项。这 份报告在 MSF CMMI 中可用。 工作项状态。存在多少活动、已解决和已关闭的工作项？这份报告列举了按状态组织的工作项。 这份报告在 MSF CMMI 中可用。

自定义报告 您可能需要一份在两种 MSF 过程模板中均不存在的报告。可以通过以下三种方法之一自定义报告： z

z z

在现有报告上使用过滤器。许多报告都提供了可用于过滤报告的参数。例如，日期、区域、迭 代和优先级过滤器均可用。使用这些过滤器来查看报告中提供数据的一个子集。请注意，这些 过滤器是临时的，浏览其他报告时，会失去这些过滤器。 自定义现有报告。如果您需要的报告类似于一种现有报告，获得现有报告的一份副本然后进行 修改往往更加轻松。例如，您可能希望查看长期风险，分析团队处理项目风险的情况如何。 新建报告。可以从零开始创建新报告。

如果修改了现有报告，或从零开始创建了新报告，那么可以将其发布到报告服务器上，使其对团队 中的其他人员可用。如果您希望修改现有报告或新建报告，可以使用以下方法之一： z z

使用 Microsoft Office Excel®，通过报告数据库中的数据创建数据透视表。 在 Visual Studio 中新建一个报告服务器项目，然后创建新报告或导入现有报告。

在 Visual Studio 中场景一个报告服务器是最强大、最灵活的报告创建与修改方法。 注意：尽管可以使用团队报告站点上提供的“报表生成器”，但 Visual Studio 报告方案对此工具 的支持不尽人意，因此不推荐使用。

更多信息 z z z

关于自定义现有报告的更多信息，请参见“如何：使用 Visual Studio Team Foundation Server 自 定义报告”。 关于创建自定义报告的更多信息，请参见“如何：为 Visual Studio Team Foundation Server 创建 自定义报告”。 关于创建长期风险报告的详尽指南，请参见“如何：使用 Visual Studio Team Foundation Server 创 建长期风险报告”。

物理体系结构 Team Foundation Server 构建于 SQL Server 2005 之上，使用 SQL Server 分析服务来聚集数据、驱 策报告。可以使用 Microsoft Excel 或 Visual Studio 2005 报表设计器来创建新报告。报告位于 SQL

Server 2005 报表服务中，可通过报告服务器 Web 站点、团队 SharePoint 项目门户或“团队资源管 理器”中的报告节点查看。图 15.1 显示了报告的物理体系结构。 :报表设计器 报告

excel 报告

Team System 数据仓库 OLAP 多维数据集 Team System 数据 仓库关系数据库

自定义结构

适配器

工作项跟踪

适配器

源代码管理

适配器

Team Foundation Build

适配器

团队测试

适配器

第三方适配器

适配器 Team System 数据库 操作存储

图 15.1 物理报告体系结构 每个 TFS 组件都维护其自己的事务数据库集。这包括工作项、源代码管理、测试、bug 和 Team Build。此数据聚合到一个关系数据库中。该数据随后放入一个联机分析处理 (OLAP) 多维数据集， 以支持基于趋势的报告和更为高级的数据分析。 TfsWarehouse 关系数据库是一个设计用于数据查询而非事务处理的关系数据库。数据从为事务处理 优化过的各 TFS 数据库传输到此仓库中，以报告为目标。仓库并非主要报告存储，但可使用它来 生成报告。TfsReportDS 数据源指向关系数据库。Team System 数据仓库 OLAP 多维数据集是一个 OLAP 数据库，通过 SQL Server 分析服务访问。该多维数据集对于提供趋势数据分析（例如“与 上月相比，本月关闭了多少 bug”）的报告非常有用。TfsOlapReportDS 数据源指向分析服务数据 库中的 Team System 数据仓库 OLAP 多维数据集。

报告系统的组件 报告系统包含以下服务器端和客户端组件。

服务器端组件 服务器端组件包括：

z z z z

报告服务器数据库。这些数据库包含报告定义、历史报告和配置数据。 报告服务器 Web 服务。此 Web 服务提供了对报告服务器的编程式访问。 报告管理器 Web 站点。此站点为用户提供了通过 Web 浏览器对报告服务器进行的访问。 Windows 服务。此服务提供了报告快照的时间安排和交付。

客户端组件 客户端组件包括： z z

浏览器。该组件提供了对报告管理器 Web 站点的访问。 团队资源管理器。该组件提供了通过 Visual Studio 对报告进行的访问。

报告开发工具 开发工具包括： z z z

Business Intelligence Designer Studio (BIDS)。该组件使开发人员能够在 Visual Studio 2005 内 设计和部署报告。 Excel。Excel 可用于通过报告存储生成数据透视表。 报表生成器。该组件允许最终用户设计专用报告。Team Foundation 报告方案并未为其提供良好 支持，因此不推荐使用。

小结 MSF Agile 和 MSF CMMI 过程模板均提供了一组默认报告，用于 bug、发布管理、测试和工作项 跟踪： z z z z

过程模板中与 bug 相关的报告使您能够查看生成和修订的是哪种类型的 bug，从而帮助识别 bug 趋势。 发布管理报告帮助您判断应用程序是否适于发布。 测试报告使您能够监视测试有效性和进度。 工作项报告使您能够评估项目的当前状态和当前项目进度。

如果需要修改现有报告或创建新报告，可以使用团队报告站点中的报表生成器，可使用 Excel 通过 报告数据库中的数据创建数据透视表，或在 Visual Studio 中创建一个新报告服务器项目。

其他资源 z

关于 Team Foundation Server 报告的更多信息，请参见： http://msdn2.microsoft.com/en-us/library/ms194922(VS.80).aspx

第 VIII 部分 设置和维护团队环境 本节内容： ¾ Team Foundation Server 部署 ¾ 为 Team Foundation Server 提供 Internet 访问

第 16 章 - Team Foundation Server 部署 目标 z z

了解单服务器和多服务器部署的优缺点。 选择一种适合您的组织的需求的部署拓扑。

概述 这一章概述了部署 Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) 的主要方法，并描 述了在组织中部署 TFS 时您将面对的关键决策点。本章解释了两种部署选项，并介绍了如何在其 中作出选择。 存在两种 TFS 部署选项：单服务器或双服务器安装。单服务器安装将数据层和应用层放置在一个 服务器上。双服务器安装将应用层和数据层拆分到单独的服务器上。除此之外，您可以将生成服务 器和源代码管理代理安装在单独的服务器上。各客户端需要访问服务器，必须安装恰当的客户端工 具。

如何使用本章 使用这一章来确定您的 TFS 部署策略。要从本章中获得最大收益，您应该： z

z

理解 TFS 体系结构。确保完全理解了 TFS 体系结构。如果您还不熟悉 Team Foundation Server 体系结构，请阅读“TFS 体系结构”一节，或阅读“第 2 章 – Team Foundation Server 体系 结构”获得更多信息。 选择一种部署策略。选择最适合您的组织需求的部署策略。如果尚未选好，请阅读“部署方案” 一节，确定哪种部署策略最适合您的团队。

TFS 体系结构 图 16.1 显示了 TFS 体系结构。

客户层 Visual Studio 2005

Office （加载项）

命令行

Internet Explorer

其他

Team Foundation 客户端 API（对象模型）

应用层

ASP.NET Team Foundation Web 服务 Team Foundation

Team Foundation 集成服务 事件和 通知服务

链接 服务

Team Foundation 数据服务

注册 服务

工作项 服务

源代码 管理服务

生成 数据服务

WSS 团队项目门户站 点 Web 部件 SQL 报表服务 报告

SQL Server 2005

数据层

工作项

方法学

生成数据

数据仓库

源代码存 储库

图 16.1 TFS 体系结构 TFS 体系结构由三层构成：数据层、应用层和客户层。这是逻辑划分，所有三层可以安装在同一台 计算机上。 Team Foundation 数据层包含 Microsoft SQL Server™ 2005。安装了多个数据库来存储工作项、版本 控制系统、测试结果和任何报告。 应用层包含集成于 Internet 信息服务 (IIS) 之中、基于 Web 的前端；Team Foundation Web 服务以 及Microsoft Office SharePoint® 服务。应用层还包含任何生成服务器和源代码管理代理服务器。 客户层包含访问 TFS 的应用程序。开发人员使用“团队资源管理器”连接团队服务器，它可作为 单独的工具安装，也可作为 Visual Studio 2005 的一部分安装。项目经理使用 Microsoft Office Excel® 或 Microsoft Office Project。还可以使用第三方工具来连接服务器。 更多相关信息，请参见“第 2 章 – Team Foundation Server 体系结构”。

部署方案 可以通过以下方法部署 TFS： z

z

单服务器部署 在一个工作组内。 使用 Microsoft Active Directory ® 目录服务。 双服务器部署

使用工作组进行单服务器部署 使用这种部署方法，您会在无活动目录域控制器的地方创建一个工作组。有一个小型团队时，可使 用这种安装模式。如果使用了这种安装模式，每个用户都需要一个服务器本地账户，这样才能够登 录服务器。对于此类型的部署，仅可安装到单服务器上，不支持双服务器安装。

使用活动目录进行单服务器部署 如果偶一个活动目录，那么就有两种部署选择。可以将数据层和应用层安装到同一个服务器上，也 可以将数据层和应用层安装到独立的服务器上。

我的组织应该使用哪种部署类型？ 要判断单服务器还是双服务器安装是您的组织的正确选择，先考虑以下问题： z z

z

我需要支持多少用户？如果计划有超过 400 名用户，考虑双服务器部署是否更适合您的需求。 我将使用 TFS 支持多少项目？如果您要支持大量项目，考虑双服务器部署是否更适合您的业 务需求。每个 TFS 实例都可支持多达 5000 个项目。如果需要支持的项目数量超过 5000，则 应考虑设置多个 Team Foundation Server 实例。 我是否有一台可专用于 TFS 的服务器？单服务器 Team Foundation Server 不是中的服务器应 专用于 TFS 功能。TFS 不应用作其他任何用途，例如作为邮件服务器、文件服务器或其他应 用程序的数据库服务器。

单服务器部署的优势 在决定是否实现单服务器部署时，考虑以下优势： z

简单性

z

可以在单独一台服务器上管理 TFS 部署的所有方面。 可以在一台服务器上为用户和组配置所有访问权力和权限。 仅有一台服务器需要安排备份和维护时间。

可用性 由于应用层和数据层都位于同一台服务器上，在计划部署时，无需考虑应用层和数据 层之间的网络限制或网络延迟。

双服务器部署的优势 在决定是否实现双服务器部署时，考虑以下优势： z z

可伸缩性。单服务器部署为最多 400 名用户而设计，而双服务器部署将允许您将此极限上扩到 2000 名用户。 故障转移。如果需要维护或维修，可以将应用层服务器重定向到不同的数据层服务器，但无法 配置和部署可作为备用或故障转移应用层服务器的额外服务器。

单服务器部署 图 16.2 展示了典型的单服务器部署。服务器上安装了 TFS 应用层和数据层，连同 SharePoint 服 务和 SQL Server 2005。

VSTF 应用服务器 （Windows 2003，ASP.NET，WSS，SQL Server 2005）

工作站

Team Foundation 集成服务

Visual Studio 2005

ASP.NET Team Foundation 数据服务

Office （加载项）

HTTP(s) WSS

命令行

团队项目门户站点

操作存储区

其他 SQL Server 2005

数据仓库

图 16.2 典型的单服务器安装

双服务器部署 图 16.3 展示了典型的双服务器安装。TFS 应用层随 SharePoint 服务安装在一个层上。TFS 数据层 随 SQL Server 2005 安装在另一台服务器上。 VSTF 应用服务器 （Windows 2003，ASP.NET，WSS，

工作站

Office （加载项）

ASP.NET

HTTP(s)

命令行

WSS

Team Foundation 集成服务 Team Foundation 数据服务

MSSQL/TCP

Visual Studio 2005

VSTF 数据库服务器 （Windows 2003， SQL Server 2005）

SQL Server 2005

操作存储区 数据仓库

团队项目门户站点

其他

图 16.3 典型的双服务器安装

其他服务器 无论是在单服务器安装还是在双服务器安装中，都可以安装一个单独的生成服务器以及代理服务器。 这些均可安装在与应用层相同的服务器上，也可以安装在不同的服务器上。

生成服务器安装 可以将生成服务器定位在单独的服务器上，改进生成性能，并减低应用层负载。例如，如果应用层 服务器性能受频繁生成的影响，可考虑将生成服务移动到单独的服务器上。

Team Foundation 代理服务器 Team Foundation 代理服务器缓存源代码管理文件的副本。如果正在通过网络访问源代码管理服务 器，而存在高延迟，则应使用代理服务器。

Team Foundation Server 拓扑 确定了使用单服务器或双服务器安装后，有一些拓扑可供您使用。拓扑的范围从简单到复杂。每种 拓扑均为某种规模的团队而设计。

简单拓扑 图 16.4 展示了一个简单的拓扑，其中 TFS 应用层和数据层组件部署在一台服务器上。TFS 代理 服务器部署到单独的服务器上。服务器可通过同一个域中的客户端工作站访问。 这种配置适合最多具有 400 名用户的开发团队或试验项目。

Team Foundation Server（单服务器） 应用层和数据层

HTTP(S) 客户端

图 16.4 简单的 Team Foundation Server 拓扑

中等拓扑 图 16.5 展示了在不同层上安装的 TFS。应用程序服务部署在一个应用层节点上，数据库部署在一 个单独的数据层节点上。

Team Test Load Agent Servers

Team Foundation Server（双服务器）

应用层

数据层

客户端

Team Build Servers

图例

客户端 HTTP(S) MSSQL/TCP .NET 远程控制

图 16.5 中等的 Team Foundation Server 拓扑 图 16.5 还展示了测试 rig（远程测试机组）和一些部署到单独的节点上的生成服务器。客户端节点 可以与服务器位于相同的域中，也可以位于与服务器有信任关系的域中。这种复杂度的拓扑是范围 在 400 到 2000 名用户的大型开发团队的目标。

复杂拓扑 图 16.6 中显示的复杂拓扑类似于中等拓扑。然而，在这种拓扑中，已通过一台应用层备用服务器 和带有 SQL 集群技术的数据层添加了故障转移组件。

Team Test Load Agent Servers

Team Foundation Server（双服务器） 应用层

APP Tier Standby

数据层

客户端

Team Build Servers

客户端 图例 HTTP(S) MSSQL/TCP .NET 远程控制

TFS Proxy

图 16.6 复杂的 Team Foundation Server 拓扑 图 16.6 还显示了一个地理上间隔很远的子域，它使用带宽有限的连接。这些客户端使用 TFS 代理 服务器改善对源代码管理的访问时间。

其他考虑事项 部署 TFS 时，考以下事项： z

z

如果您已经设置了一个 SharePoint 服务器，并希望使用它来托管 Team Foundation Server SharePoint 站点，可以将 TFS SharePoint 站点移动到另一台服务器上。有关更多信息，请参见： http://blogs.msdn.com/bharry/archive/2006/10/30/moving-your-tfs-sharepoint-site.aspx 将 OLAP 引擎和多维数据集移动到已经证明对大型团队有益的第三台机器上。可以在数据层上 设置 SQL 集群，并在一个节点上使用 SQL 进行活动/活动配置，将 OLAP 放置在另一个节点 上，各自作为对方的故障转移。有关更多信息，请参见： http://msdn2.microsoft.com/en-us/library/aa721760(vs.80).aspx 和 http://msdn2.microsoft.com/en-us/library/ms252505(VS.80).aspx

Team Foundation Server 伸缩和备份策略 作为 Team Foundation Server 安装和部署工作的一部分，您必须确定如何继续管理服务器的备份和 故障转移。您选择的备份和故障策略取决于安装的规模以及组织可用的设施和资源。由于数据层在 SQL Server 2005 上生成，您采纳的策略将基于当前用于 SQL Server 备份的方法。 如果您当前对 SQL Server 2005 安装进行了镜像或集群，那么可以采用与 TFS 数据层相同的方法。 You also need to decide how to manage failure of the application-tier server.如果希望支持应用层故障转 移，您将需要一个备份应用层服务器，而且必须能够快速故障转移到该服务器。

为您的企业选择恰当的安装和备份/还原策略。 安装 TFS 时，您需要作出一些关于安装和备份/还原策略的选择。在决定安装策略时，应考虑以下 事项： z z z z z z

团队规模 项目数量 项目规模 团队位置 故障转移需求 备份需求

推荐的 Team Foundation Server 硬件 通常情况下，项目较少的小型团队可以使用单层安装，而较大的团队则需要双层和更快的硬件。单 层与双层安装的选择也会影响您的备份和故障转移机制。 使用表 16.1 帮助您觉得使用单层还是双层安装，并识别支持团队所需的硬件。 配置

层

CPU

硬盘驱动器

内存

一台服务器，少于 20 名用户

应用层和数据层 服务器

单处理器。 2.2 gigahertz (GHz)

8 gigabytes (GB)

1 GB

一台服务器，20 至 100 名用 户

应用层和数据层 服务器

双处理器， 2.2 GHz

30 GB

2 GB

一台服务器，100 至 250 名用 户

应用层服务器

单处理器， 2.2 GHz

20 GB

1 GB

数据层服务器

双处理器，2.2 GHz

80 GB

2 GB

应用层服务器

双处理器，2.8 GHz

40 GB

4 GB

数据层服务器

四处理器，2.7 GHz

直连存储， 14,000 – 15,000 RPM RAID 0 spindle

16 GB

两台服务器，250 至 2000 名 用户

表 16.1 TFS 部署所需硬件

备份和故障转移策略 考虑备份和故障转移策略时，您需要考虑到损失服务器对团队生产率的影响。

备份 应将备份策略作为 TFS 安装的一部分进行计划。您必须考虑： z

备份频率。

z z

完整备份和增量备份的频率。 备份所需存储，例如现场和远距离备份。

可以使用为任何 SQL Server 2005 数据库使用的相同的标准备份实践。 在以下三种方案中，可以使用备份来还原 TFS： z z z

仅数据还原。 单服务器部署全面还原。 双服务器部署全面还原。

若数据层崩溃，则使用仅数据还原。可以使用备份数据和记录来恢复整个数据库。 服务器还原在服务器故障时使用。此时，可以将整个数据库还原到另一台计算机上。

应用层备用服务器 尽管应用层服务器上未备份任何数据，但服务器可也可发生故障。要降低这种故障的成本，应考虑 考虑使用一台热备用服务器，在应用层上实现故障转移。

故障转移 考虑是否为 TFS 提供故障转移解决方案时，应考虑提供故障转移服务器所需硬件的成本和在 TFS 不可用时企业损失生产率的成本。 故障转移会给您的安装增加额外的复杂度，从而增加维护开销。决定策略时，必须将这种成本纳入 成本考虑事项。 集群在资源和维护方面成本高昂，如果您的组织已经提供了管理集群服务器的资源，推荐使用集群。 镜像也有成本，但不像集群那么高。镜像的优势在于使您能够将主要服务器脱机维护。如果您的组 织能够设置和维护第二个数据层服务器，那么应考试镜像。

数据层 集群数据层服务器 如果您的组织有必要的资源，那么应考虑在一个集群中设置专用服务器。集群将提供对数据层的无 中断访问。但请注意，集群的硬件需求非常高。设置和维护集群的资源成本非常高昂。 进行集群时，TFS 通过一个被动节点、一个活动节点和一个定额设备服务器支持配置。数据层故障 转移到被动节点时，此节点获得定额和数据层的所有权。 将 TFS 安装到一个集群中之前，必须为安装准备集群。关于 SQL Server 2005 集群的更多信息， 请下载“SQL Server 2005 故障转移集群白皮书”，地址为： http://www.microsoft.com/downloads/details.aspx?familyid=818234dc-a17b-4f09-b282-c6830fead499&di splaylang=en

镜像数据层服务器 镜像服务器涉及将一台服务器上的数据与该数据在其他服务器上的副本同步。数据层服务器是主要 服务器，带有镜像数据的服务器是备份或镜像服务器。如果您的数据层服务器出现故障，可以手动 切换到镜像服务器。

拥有镜像服务器使您能够将主服务器脱机维护和修理，如果您的主数据层服务器发生故障，这也会 提供一种快速还原机制。 镜像可以是同步的，也可以是异步的。在一种称为角色切换的移动中，可以将服务器从主服务器交 换为镜像服务器。角色切换发生时，镜像取代主服务器的角色。如果较早的主服务器依然可以，它 可以取代镜像的角色。大体上，角色可以来回切换。 对于 TFS，自动切换并不支持，反之，您必须使用手动切换。

要为数据层配置 SQL 镜像 1.

2.

3.

4.

5.

6.

进行数据库和事务日志的完整备份。 备份报告服务加密密钥。 在镜像服务器上安装 SQL Server 2005。 从数据层将数据还原到镜像服务器上。 对于数据层主服务器上的每一个数据库，运行“配置数据库镜像安全性向导”来配置其镜像服 务器。 启动镜像。

故障转移一台镜像的服务器 您必须执行以下步骤，手动故障转移镜像的服务器： 1.

2.

3.

4.

5.

在 TFS 应用层上 a 重新配置报表服务，使用新服务器。 b 停止默认 Web 站点。 c 停止 SharePoint Web 站点。 d 停止 SharePoint 计时服务。 e 停止 TfsServerScheduler 服务。 f 停止 ReportServer 应用程序池， g 停止 TFS App Pool 应用程序池。 在镜像数据层服务器上，确保添加了正确的服务账户。 将各数据库从主服务器故障转移到镜像服务器。 在新服务器上生成数据仓库。 配置应用层服务器，使用镜像层服务器，如下： a. 从命令提示符中，运行 TFSAdminUtil RenameDT MirrorDataTierServer。 b. 重启 IIS。 c. 更改报表服务连接字符串，引用镜像数据层服务器。 d. 更改 SharePoint 服务器，镜像数据层服务器。 e. 启动 SharePoint 计时服务。 f. 启动 TfsServerScheduler 服务。 g. 启动 ReportServer 应用程序池。 h. 启动 TFS App Pool 应用程序池。 i. 启动报表服务。 j. 调用 StampWorkItemCache Web 服务

应用层 故障转移应用层 设置主应用层服务器，可以添加一台热备用计算机，允许应用层的热故障转移。

备用硬件和软件

备用服务器无需与主服务器等同，但必须匹配应用层的硬件需求。将 TFS 应用层软件安装到热备 用服务器上。 必须确保两台服务器具有相同的配置，包括相同的用户账户、权限变更和软件更新。主计算机上的 任何更新都必须应用于热备用服务器。 为了最小化故障转移的问题，您必须配置网络适配器，使用与主计算机和备用计算机相同的主机名。 有许多方法可以实现这一目标。

故障转移应用层服务器 手动故障转移应用层服务器。主服务器发生故障时，必须完成以下步骤，手动激活热备用服务器。 可以在备用服务器上运行 TFSAdminUtil 实用工具，传递 ActivateAT 命令，来帮助故障转移主服 务器。 为了热故障转移服务器： 1.

2.

在备用应用层服务器被激活时，将原服务器脱机。 在备用服务器上 a. 作为管理员登录。 b. 运行 TFSAdminUtil，传递 ActivateAT。 c. 在备用服务器上启动 Web 服务、 此命令将 z 在 TFS 集成数据库中注册热备用服务器名称。 z 将热备用应用层服务器连接到活动的数据层服务器。 z 验证将正确的应用层服务器连接到了正确的数据层服务器。

关于如何激活应用层故障转移服务器的更多信息，请参见“如何：激活故障转移应用层服务器”， 地址为：http://msdn2.microsoft.com/enus/library/ms252501 (VS.80).aspx

小结 TFS 体系结构有三层：应用层、数据层、客户层。安装服务器时，可以选择将应用层和数据层安装 在同一台服务器上，或分别安装在单独的服务器上。TFS 部署选择主要取决于您希望支持的用户数 量。选择了一种支持团队需求的拓扑之后，您可以决定您需要的是哪种级别的备份和故障转移支持。 对于数据层，可以使用与其他 SQL Server 2005 备份相同的备份机制。对于故障转移支持，可以选 择镜像或集群数据层服务器。 应用层并不支持自动故障转移。如果需要支持快速故障转移，可以提供一个能够手动故障转移的热 故障转移服务器。

其他资源 z z z

z

关于安装 TFS 的更多信息，请参见“Visual Studio 2005 Team Foundation 安装指南”，地址为： http://go.microsoft.com/fwlink/?linkid=40042 关于 TFS 可伸缩性限制的更多信息，请参见“Team Foundation Server 容量计划”，地址为： http://blogs.msdn.com/bharry/archive/2006/01/04/509314.aspx 关于如何将 OLAP 多维数据集和分析引擎移动到单独的服务器的更多信息，请参见“如何：将 数据仓库 SQL Server 分析服务数据库移动到单独的服务器”，地址为： http://msdn2.microsoft.com/en-us/library/aa721760(vs.80).aspx 关于 SQL Server 2005 集群的更多信息，请下载“SQL Server 2005 故障转移集群白皮书”，地 址为：

z z z

z z z z z z

z z

z z

http://www.microsoft.com/downloads/details.aspx?familyid=818234dc-a17b-4f09-b282-c6830fead49 9&displaylang=en 关于创建 SQL 故障转移集群的更多信息，请参见“如何：新建 SQL Server 2005 故障转移集 群（设置）”，地址为：http://uat.technet.microsoft.com/en-us/library/ms179530(SQL.90).aspx 关于如何为数据层设置 SQL Server 集群的更多信息，请参见“集群数据层服务器”，地址为： http://msdn2.microsoft.com/en-us/library/ms252505(VS.80).aspx 关于如何将 TFS SharePoint 站点移动到另一台服务器的更多信息，请参见“迁移您的 TFS SharePoint 站点”，地址为： http://blogs.msdn.com/bharry/archive/2006/10/30/moving-your-tfs-sharepoint-site.aspx 关于 Team Foundation Server 可伸缩想的更多信息，请参见 Brian Harry 的博客，地址为： http://blogs.msdn.com/bharry/archive/2005/12/09/502190.aspx 关于灾难还原计划的更多信息，请参见“Visual Studio Team System 用户培训”，地址为： http://www.microsoft.com/technet/itshowcase/content/vs05teamsystemnote.mspx 关于 Team Foundation Server 备份故障与还原的更多信息，请参见“确保 Team Foundation Server 可用性”，地址为：http://msdn2.microsoft.com/en-gb/library/ms253159(VS.80).aspx 关于集群数据层服务器的更多信息，请参见“集群数据层服务器”，地址为： http://msdn2.microsoft.com/en-gb/library/ms252505(VS.80).aspx 关于镜像 Team Foundation Server 数据层的更多信息，请参见“镜像 Team Foundation 数据层 服务器”，地址为：http://msdn2.microsoft.com/en-gb/library/aa980644(VS.80).aspx 关于为数据层配置 SQL Server 镜像的更多信息，请参见“如何：为 Team Foundation 数据层 服务器配置 SQL Server 镜像”，地址为： http://msdn2.microsoft.com/en-us/library/aa980629(VS.80).aspx 关于故障转移数据层的更多信息，请参见“如何：故障转移到镜像的数据层服务器”，地址为： http://msdn2.microsoft.com/en-gb/library/aa980627(VS.80).aspx -{}关于在主服务器不可用时故障转移到数据层的更多信息，请参见“如何：在主数据层服务器不 可用时故障转移到镜像数据层服务器”，地址为： http://msdn2.microsoft.com/en-gb/library/aa980528(VS.80).aspx 关于如何激活应用层故障转移服务器的更多信息，请参见“如何：激活故障转移应用层服务器”， 地址为：http://msdn2.microsoft.com/enus/library/ms252501 (VS.80).aspx 关于激活应用层故障转移服务器的更多信息，请参见“激活故障转移应用层服务器”，地址为： http://msdn2.microsoft.com/enus/library/ms252501 (VS.80).aspx

第 17 章 – 为 Team Foundation Server 提供 Internet 访问 目标 z z z

了解关键的远程访问方案以及何时应用它们。 通过 Internet 为您的 Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) 提供远程 访问。 通过使用 Team Foundation 服务器代理改进远程访问性能。

概述 本章解释了如何通过 Internet 为 TFS 提供远程访问。可以从以下三个选项中挑选一种，以便提供 远程访问： z z z

可以通过虚拟专用网（VPN）提供对TFS的访问。 可以通过一个反向代理提供对 TFS 的访问，如 Microsoft Internet Security and Acceleration (ISA) Server。 可以在外部网上托管您的 TFS 服务器。

先于 Service Pack 1 (SP1) 的 TFS 版本仅支持 VPN 访问。TFS SP1 添加了对 Basic 身份验证的 支持。这启用了外部网和反向代理解决方案以及 VPN。

如何使用本章 使用这一章，为通过 Internet 的远程访问设置 TFS 服务器。要从本章中获得最大收益，您应该： z z z

使用方案列表。参考方案列表，快速确定应采纳哪种方法来为您的服务器提供外部 Internet 访 问。 使用参考步骤。使用这一章中的步骤作为详尽指南，帮助您安装和配置证书和安全套接字层 (SSL) 访问，以便将其随 Basic 和摘要身份验证一起使用。 使用“改进远程访问性能”一节。阅读“改进远程访问性能”一节，识别减少需通过 Internet 发 生的流量数的方法。

关键策略 以下是为 TFS 服务器提供远程访问的解决方案策略： z z z

使用 VPN 连接。您的 TFS 位于内部网，外部用户通过 VPN 访问它。内部用户直接访问 TFS。 通过反向代理发布 TFS。您的 TFS 位于内部网，一台或多台反向代理机器（如 ISA Server） 将 Internet 客户端请求传入您的 TFS。 将 TFS 定位于外部网中（“寄宿方案”）。仅有外部客户端访问您的 TFS，它位于防火墙外 的外部网中。

常见方案 z

远程办公室。如果您正通过 VPN 访问支持远程用户，使用 VPN 解决方案。这是支持的最简 单解决方案，提供得到了很好理解的安全性，允许远程访问所有 TFS 功能，允许您使用 TFS 代 理改进性能。

z z

海外团队。如果您在支持没有 VPN 访问或无权访问域的远程用户，可使用反向代理方案。、 这种解决方案的设置更加困难，但使远程用户能够访问位于内部的TFS，而无需VPN。 托管的社区。如果您正在支持一组远程用户，他们将使用专供其使用的 TFS 安装，例如社区 开发站点，则使用外部网方案。这种解决方案给您提供了远程用户与内部网络资源之间的最大 分离。

使用 VPN 连接。 图 17.1 展示了通过 VPN 公开 TFS 的体系结构。 内部

Internal TFS Server

TFS Web 服务 API

工作站

防 火 墙

团队项目门户 SQL 报表服务

工作站

SQL Server

AD 用户存储

图 17.1 VPN 上的 TFS 体系结构 使用这种方法，您的软件开发团队使用内部网络中 TFS 的 VPN 直连。如果您使用无 SP1 的 TFS， 或者需要集成 Windows 身份验证，则使用 VPN 连接是惟一的选择。TFS 设计用于在低带宽环境 中工作，例如 VPN 访问，并在用于这种环境中时提供可接受的性能。

优点 z z z

所有 TFS 功能均有效，包括 TFS 代理。 这种方法支持集成 Windows 身份验证的使用，并使您能够利用现有企业基础结构。 如果已有 VPN 设置，那么这是最容易采纳的解决方案。

缺点 z

VPN 解决方案不会为您的基础结构设置，对远程用户可能也不可用。

关于创建 VPN 的更多信息，请参见：http://support.microsoft.com/kb/324747 .

通过反向代理发布 TFS

使用这种方法，您会在内部忘中安装一个 TFS 服务器，并使用 ISA Server Web 发布功能将其公 开给外部网。远程用户通过 SSL 访问 TFS，并使用 Basic 身份验证。只有在安装了 TFS SP1 时， 这种选项才能正常工作。

外围无域控制器的网络 图 17.2 展示了使用内部网中的一个域控制器公开 ISA 上的 TFS 的体系结构。 内部

Internal

Perimeter

HTTPs

工作站

HTTPs 防 火 墙

ISA 反向代理

防 火 墙

TFS Server TFS Web 服务 API 团队项目门户 SQL 报表服务

用户在 ISA 处 进行身份验证

LDAP AD 用户存储

图 17.2 ISA 上的 TFS，内部网中有一个域控制器的体系结构 如果外围网络中无域控制器，可以在防火墙上打开一个端口，允许轻量级目录访问协议 (LDAP) 连 接从 ISA Server 接入您的内部域控制器，专用于验证外部 TFS 用户。

外围有域控制器的网络 图 17.3 展示了使用外围网络中的域控制器公开 ISA 上的 TFS 的体系结构。

外围防火墙 z 代理 z 身份验证 z 服务路由

内部

外围

内部

TFS Server

工作站

防 火 墙

防 火 墙

ISA 反向代理

TFS Web 服务 API 团队项目门户 SQL 报表服务

AD 用户存储

单向信任

边缘防火墙 z 不进行身份验证 z 限制端口 z 识别签名 z 侵入检测

AD 用户存储

边缘防火墙 为 Kerb/AD 开放端口

图 17.3 ISA 上的 TFS，外围网络中有域控制器的体系结构 如果外围网络中确实有域控制器，远程用户可以直接依靠外围域控制器进行身份验证。内部和外围 域控制器之间的单向信任使外部用户可以访问 TFS 服务器。内部用户直接访问 TFS 服务器，使用 集成 Windows 身份验证。

优点 z z z

ISA Server 这样的反向代理对用户进行省份验证，并检测流量。 远程用户无需访问该域。 远程用户无需 VPN 访问。

缺点 z z z z z z

无法在远程位置使用 TFS Proxy。 远程用户无法向 TFS 组添加用户。 远程用户无法向源代码管理中的文件夹添加 Microsoft Active Directory® 组。 远程用户无法远程启动或管理生成。 远程用户无法创建新团队项目。 远程用户无法向您的 TFS 发布测试结果。

注意：只要使用 Basic 身份验证，就应使用 SSL。Basic 身份验证以明文传输凭证。使用 SSL 来 保护这些信息。

将 TFS 定位于外部网中（“寄宿方案”） 图 17.4 展示了在外部网中托管 TFS 的体系结构。 内部

Internal

Perimeter TFS Server

TFS Web 服务 API

工作站

防 火 墙

团队项目门户 SQL 报表服务

防 火 墙

SQL Server

AD 用户存储

图 17.4 TFS 托管于外部网的体系结构 使用这种方法，您要在外围网络中安装整个 TFS 基础结构——包括应用层和数据层，脱离了内部 的 Intranet 。无论来自内部用户还是外部用户，对 TFS 的所有连接都通过 Internet 传输。TFS 在 有无域控制器 (DC) 的情况下均可工作。如果您的外围网络无法访问 DC，TFS 的活动目录服务功 能将无法正常工作。例如，将用户添加到 TFS 组、将活动目录组添加到源代码管理的文件夹中， 在没有 DC 的情况下均无法成功完成。只有在安装了 TFS SP1 时，这种选项才能正常工作。

优点 z z

TFS 用户与内部网清晰隔离。 远程用户无需访问该域。

缺点 z z z z z

无法在远程位置使用 TFS Proxy。 远程用户无法启动或管理生成。 远程用户无法创建新团队项目。 远程用户无法向您的 TFS 发布测试结果。 内部用户必须通过 SSL 连接到外部网 TFS，与外部用户一样。

注意：只要使用 Basic 身份验证，就应使用 SSL。Basic 身份验证以明文传输凭证。使用 SSL 来 保护这些信息。

Basic 身份验证 / SSL 如果您使用的是 TFS SP1，而且希望支持外部网或反向代理方案，则需通过在 TFS 应用层上配置 IIS 来启用 Basic 身份验证。使用 Basic 身份验证，登录凭证使用未受保护的 Base64 编码格式通 过 Internet 传递。要保护客户端的凭证，应仅使用应用了 SSL 的 Secure HTTP (HTTPS) 连接上的 Basic 身份验证。 使用 Internet Server API (ISAPI) 过滤器，使远程客户端使用 SSL 上的 Basic 身份验证进行连接， 而本地客户端依然通过集成 Windows 身份验证连接。ISAPI 过滤器查找已配置为“外部/Internet” 的客户端，删除 401 响应的 NTLM 身份验证，从而使这些客户端使用其他身份验证方法，例如

Basic 身份验证。

更多信息 z

z

z

关于如何配置 TFS 服务器通过远程连接要求 Basic 身份验证和 HTTPS 的更多信息，请参见 “演练：设置 Team Foundation Server 要求 HTTPS 和 Secure Sockets Layer (SSL)”，地址为： http://msdn2.microsoft.com/en-us/library/aa833873(VS.80).aspx 关于设置 ISAPI 过滤器的更多信息，请参见“演练： 使用 Secure Sockets Layer (SSL) 和一个 ISAPI 过滤器设置 Team Foundation Server”，地址为： http://msdn2.microsoft.com/en-us/library/aa833872(VS.80).aspx 关于用于 TFS 的 ISAPI 过滤器的更多信息，请参见 James Manning 的博客文章“TFS 外部 网 ISAPI 过滤器机制”，地址为： http://blogs.msdn.com/jmanning/archive/2006/10/27/the-tfs-quot-extranet-quot-isapi-filter-mechanics. aspx

Team Foundation Server 代理 图 17.5 展示了使用 Team Foundation Server 代理的体系结构。 内部

Internal TFS Server

工作站

TFS Web 服务 API 防 火 墙

团队项目门户 工作站

SQL 报表服务

TFS Proxy SQL Server

AD 用户存储

图 17.5 TFS 代理体系结构 要启用远程访问，TFS 代理并非必不可少，但它是源代码管理文件的可选缓存。要帮助改进远程团 队体验的性能，可以在远程办公室安装一个 TFS 代理，通过 VPN 连接到您的 TFS。这会提高性 能，因为源代码管理文件会缓存在远程办公室的代理服务器上。只要远程客户端需要访问源代码管 理存储库中的源代码，就会请求 TFS 代理中的源代码。随后，代理将从其缓存返回一个本地版本 （如果可用）。如果源代码未在缓存中，代理将从远程 TFS 服务器请求源代码。这可以减少网络 流量，并提高远程位置的源代码管理响应度。

改进代理性能的提示 考虑一下改进代理性能的建议： z

z z

z z

确保启用了缓存，并监视缓存的性能。定期监视代理服务器上的性能计数器（默认安装）和事 件日志（检查错误和警告），查看代理性能。请注意，TFS 代理将缓存性能统计数据保存到一 个可扩展标记语言 (XML) 文件中，名为 ProxyStatistics.xml，您可更改保存这些统计数据的时 间间隔。ProxyStatistics.xml 文件位于代理安装目录内的 App_Data 文件夹中。 运行预定任务，定期为代理服务器检索最新文件。这有助于确保文件的最新版本在代理缓存中 可用，并确保对这些文件的后续请求均命中缓存。 如果您知道如何通过低带宽（小于 3 megabits 每秒 [Mbps]）网络下载大文件，则将 Web.config 中的 executionTimeout 配置设置为恰当的值。默认值为 1 小时 <httpRuntime executionTimeout="3600"/>。 如果代理将在很长一段时间内被下载，应在客户端上禁用代理，防止无成果的重新连接。默认 情况下，重新连接会每隔 5 分钟尝试一次。 考虑使用工作区掩蔽，避免特定工作区被查看，避免不必要的文件传输。掩蔽会隐藏特定工作 区文件夹，使之无法被查看，增加性能带宽，并通过防止您当前不需要的文件和文件夹复制到 本地工作区中来节省本地磁盘空间。尽管您可以在工作区中掩蔽一个现有文件夹映射，但更好 的方法是创建一个以被掩蔽为目的的新文件夹映射。

关于这些性能优化指导原则的更多信息，请参见本指南中“指南：源代码管理指导原则”内的“分 布式/远程开发”。

镜像账户 要在远程办公室支持 TFS 代理，仅能通过 VPN 连接。然而，如果您已经使用外部网或反向代理 方案为需要 TFS 代理的小型远程团队部署了 TFS，可以使用镜像账户来启用代理。 为启用代理，可以在 TFS、TFS 代理和所有远程客户端计算机上使用带有匹配的用户名和密码的工 作组账户。需要在三个不同的位置维护准确的用户名/密码匹配这一事实增加了管理时间，也使这种 功能仅限于小型远程团队。 更多信息 z z z

要进一步了解 TFS 代理，请参见“Team Foundation Server 代理和源代码管理”，地址为 http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx . 关于管理 TFS 代理的更多信息，请参见“管理到 TFS 代理的远程连接”，地址为： http://msdn2.microsoft.com/en-us/library/ms 182023 (VS. 80).aspx 关于 TFS 代理疑难解答的更多信息，请参见“TFS 服务器代理疑难解答”，地址为： http://msdn2.microsoft.com/en-us/library/ms400681(VS.80).aspx

远程生成服务器 图 17.6 展示了使用远程生成服务器的体系结构 。 Internal 内部 工作站

TFS Proxy

TFS Server

防 火 墙

TFS Web 服务 API

工作站

团队项目门户 SQL 报表服务 Intemal Build Server

Remote Build Server

Remote Drop Location

SQL Server

Intemal Drop Location AD 用户存储

图 17.6 远程生成服务器体系结构 要进一步改进远程团队性能，可以在远程办公室设置一个生成服务器。如果远程办公室已经安装了 TFS 代理，它将与其他源代码管理客户端一样工作，在每次生成钱从代理中获取代码。远程生成服 务器具有以下优势： z z

来自远程团队的团队生成会影响该团队的生成服务器，而不是增加内部生成服务器的负载。 远程生成为远程团队提供二进制文件，无需通过网络传输二进制文件。

不会将远程生成服务器作为内部生成服务器所生成的生成的完全替代品。即便是远程生成与内部生 成得自同一版本的源代码，您也会看到不同的行为，因为服务器之间的生成或源代码配置是有差别 的。作为一条指导原则，将重要的测试在内部生成上执行，特别是在接近发布时。 注意：应用层在端口 9191 上与生成服务器通信。如果您有一个远程生成服务器，应设置防火墙， 使应用层能够在此端口上连接。

小结 如果您使用的是无 SP1 的 TFS，则应使用 VPN 来提供远程访问。如果您使用的是 TFS SP1，则 可使用 SSL 上的 Basic 身份验证，将 TFS 放置在外部网中，或通过反向代理进行访问。 如果需要提高远程访问性能，特别是在 VPN 方案中，可以安装并配置 TFS 代理，在远程位置缓 存源代码管理文件。

其他资源 z z z z z z z

关于为远程开发设置 TFS 的更多信息，请参见“演练：为远程开发位置设置 TFS”，地址为： http://msdn2.microsoft.com/en-us/library/ms242919(VS.80).aspx 关于使用 SSL 设置 TFS 的更多信息，请参见“演练：使用安全套接字层 (SSL) 设置 Team Foundation Server”，地址为：http://msdn2.microsoft.com/en-us/library/ms242875(VS.80).aspx 关于 TFS Basic 和摘要身份验证的更多信息，请参见“Team Foundation Server、Basic 身份验 证和摘要身份验证”，地址为：http://msdn2.microsoft.com/en-us/library/aa833874(VS.80).aspx 要进一步了解 TFS 代理，请参见“Team Foundation Server 代理和源代码管理”，地址为 http://msdn2.microsoft.com/en-us/library/ms252490(VS.80).aspx . 关于管理 TFS 代理的更多信息，请参见“管理到 TFS 代理的远程连接”，地址为： http://msdn2.microsoft.com/en-us/library/ms253156(VS.80).aspx 关于 TFS 代理疑难解答的更多信息，请参见“TFS 服务器代理疑难解答”，地址为： http://msdn2.microsoft.com/en-us/library/ms400681(VS.80).aspx 关于检查 TFS 代理性能的更多信息，请参见： http://msdn2.microsoft.com/en-us/library/ms252455(VS.80).aspx

第 IX 部分 Visual Studio 2008 Team Foundation Server 本节内容： ¾ Visual Studio 2008 Team Foundation Server 的新功能

第 18 章 - Visual Studio 2008 Team Foundation Server 中的新 功能 Microsoft® Visual Studio® 2008 Team Foundation Server 引入了很多新特性和新功能。主要进行了以 下更改： z z z z

管理、操作和安装。已对安装进行了简化和改进，以减少安装时间和支持更多部署方案。 生成。生成包括连续集成、预定生成以及生成开箱即用的队列解决方案。已经对生成管理和可 扩展性进行了简化，UI 具有更多功能。 版本控制。版本控制包括更好地支持脱机工作并且提高了性能。 工作项跟踪。工作项跟踪包括改进的查询生成器和改进的对工作项附件的支持。

下面列出并简要介绍了这些产品的更改，随后的表解释了这些更改对本指南的影响。本章可以帮助 您的 Microsoft Visual Studio Team Foundation Server 升级计划。

管理、操作和安装 z

z

z z z z z

简化的安装 – 与 Visual Studio 2005 TFS 相比安装变得更加容易、更加快捷。改进的部分包括： 取消了分离数据层的安装并且不再需要域帐户。Team Foundation Server 2008 支持内置的计算机 帐户（如网络服务）（如果可能）。 支持 SharePoint 2007 – 添加了对 SharePoint 2007 和 Windows SharePoint Services 3.0 的支 持。Team Foundation Server 2008 将在 Team Foundation 应用层服务器中的单独服务器上支持 SharePoint。 支持 Windows Server 2008 – 支持下一个版本的 Microsoft Windows Server™，例如 Microsoft Windows Server 2008 和 Internet Information Services (IIS) 7.0。 支持 X.509 客户端证书 – 支持使用 X.509 客户端证书提高身份验证安全性。 大型组同步 – 提高了性能和健壮性，并且将能够支持大量用户，在一个 TFS 的实例中大约有 30,000 或更多用户。 支持 SQL 命名的实例 – 允许在多个 TFS 实例之间与其他应用程序共享 SQL Server。这允许 不同的 TFS 实例使用同一个安装好的 SQL Server 2005。 支持非默认端口 – 提高了可配置性，可支持其他网站和端口。

生成 z

z z z z

z z z z

连续集成生成 – 支持创建生成触发器，它允许您精确配置应该启动连续集成生成的时间。例如， 您可以设置一个触发器，以便每次签入都启动生成，还可以设置滚动式生成，使启动生成的频 率不会高于 X 分钟一次。 支持生成队列 – 支持生成队列和队列管理。当多个签入可能排队等候多个生成时，这对于连续 集成特别有用。 预定生成 – 支持预定生成，可以根据组织的需要将其配置为在指定的时间启动。 丢弃管理 – 支持丢弃管理，使您能够设置何时自动删除生成的策略。 指定生成属性 – 允许您指定应该生成的源代码和源代码的版本，以及生成类型的其他生成属 性。有很多更明显的属性可以用于自定义生成。此外，队列生成时，可以传递 MSBuild 命令行 参数。 生成目标的可扩展性 – 提高了生成目标的可扩展性。例如，您现在可以在生成每个 Visual Studio 解决方案或项目之前和之后轻松执行目标。 生成管理 – 允许您从 Visual Studio 中停止和删除生成。 生成配置 – 简化了指定作为生成的一部分运行的测试的功能。 生成项目文件位置灵活性 – 提供了在版本控制层次结构中的任何位置存储 MSBuild 项目文 件（及其关联的 rsp 文件）的功能，而不强制使用 TeamBuildTypes 文件夹。

z z z z

支持 GUI 测试 – 允许作为生成的一部分运行图形用户界面 (GUI) 测试。 签入策略 – 支持新的签入策略，该策略在连续集成生成中断时防止用户签入代码。 管理生成服务器 – 改进了管理多个生成机器的能力。 工作区映射 – 生成定义可以与“实际”工作区关联，这意味着可以检索多个团队项目中的代码， 可以指定客户端映射等等。将在 GUI 中而不是 workspacemapping.xml 中管理工作文件夹映射

版本控制 z z

z z z z

z z z

注释 – 支持注释功能，该功能允许开发人员检查源代码文件并逐行查看有关上次更改每个部分 代码的人员的详细信息。 文件夹差别 – 支持文件夹的比较，对文件夹的内容进行递归比较以便识别不同的文件夹。文件 夹差别可以比较本地文件夹与本地文件夹、本地文件夹与服务器文件夹以及服务器文件夹与服 务器文件夹。 破坏 – 支持破坏功能，即从版本控制系统中删除文件和文件夹的功能。破坏之后，无法对破坏 的文件和文件夹进行恢复。 签出时获得最新版本 – 将其签出时，包括用于下载最新版本的文件的选项。 工作区通配符映射 – 允许映射掩蔽文件夹下的文件夹或文件以及通配符，从而可以映射文件夹 中的所有文件，而不映射子文件夹。 性能改进 – 增强了各种版本控制性能，从而提高了版本控制各个方面的性能。尽管较小的服务 器/项目（< 10,000 个文件）的收益不大，但较大项目（尤其是文件数量将近几十万的项目）将 收益很大。 Team Foundation Server 2008 命令行帮助 – 支持使用 tf 工具获得命令行帮助的功能。通过运 行“tf help”获得帮助，并且通过运行“tf command /help”可获得有关各个命令的帮助。 脱机改进 – 改进了脱机的体验，并且将 tfpt 联机功能集成到 Visual Studio 集成开发环境 (IDE) 中以便回到联机状态。 签入重写捕获的信息 – 支持向仓库添加签入策略重写。

工作项跟踪 z 附件改进 – 支持使用拖放来添加附件，并且允许多次选择附加的文件。 z 查询生成器 – 从以下几个方面改进了查询生成器的可用性： 现在可以基于当前项目进行下拉筛选 改进了 MRU 列表 列拖放 按住 SHIFT 并单击鼠标可对多个列进行排序

与 Visual Studio 2005 Team System 的兼容性问题 Visual Studio 2008 Team Foundation Server 客户端能够使用 Visual Studio 2005 Team Foundation Server，并且 Visual Studio 2005 客户端也能够使用 Visual Studio 2008 Team Foundation Server，只 是存在以下兼容性问题。 z

z

Visual Studio 加载项 – 需要对客户端 Visual Studio 加载项重新进行编译（或更改其策略）， 因为 Team Foundation Server 对象模型 (TFSOM) 程序集版本将发生更改并且加载项需要绑定 到新的程序集。 团队生成 – 大多数生成操作（如列出生成定义、启动和停止生成以及检查生成报告）将使用 Visual Studio 2005 TFS 和 Visual Studio 2008 客户端和服务器的组合。已知问题如下：

1.

2.

3.

4.

5.

6.

一个 Visual Studio 2008 Team Foundation Server 实例将只使用 Visual Studio 2008 Team Foundation Server 生成服务器。 要使 Visual Studio 2005 客户端在 Visual Studio 2008 Team Foundation Server 实例上启动 一个生成，需要将生成定义存储在 $/<TeamProject>/TeamBuildTypes/<name> 中。 对 tfsbuild.proj 文件中的属性（位于 Team Foundation Server 2008 的数据库中）所做的更 改将不会在数据库中进行更新，也不会再保持同步。 当使用 Team Foundation Server 2008 中的连续集成功能时，Visual Studio 2005 客户端将能 够启动一个生成，但是它不能对生成进行排列，不能查看队列中生成的列表，也不能查看 生成代理的列表等等。 不能使用 Visual Studio 2008 Team Foundation Server 客户端在 Visual Studio 2005 TFS 服 务器上创建新的生成类型。 当使用 Visual Studio 2008 Team Foundation Server 客户端时，无法更改对话框中用于在 Visual Studio 2005 Team Foundation Server 上启动生成的参数。

对指南的影响 Visual Studio 2005 Team Foundation Server 指南

Visual Studio 2008 Team Foundation Server 指南

双服务器部署将支持多达 2000 个用户。 可以使用双服务器部署支持多达 30,000 个用户 作为部署的一部分，用户需要更正域帐 户。 使用自定义解决方案来创建连续集成生 成。 将自动测量作为生成的一部分以度量生 成的质量。

不再需要域帐户，可以使用内置的计算机帐户，如网络服 务帐户。 可以使用 Visual Studio 生成触发器创建和配置连续集成 生成或滚动生成。 作为生成步骤的一部分，生成测试列表并指定运行测试的 内容非常容易。有可能作为自动生成测试的一部分运行 GUI 测试。 必须将生成类型放置在特定的文件夹中， 生成定义项目文件 (tfsbuild.proj) 可以存储在版本控制层 团队生成才能识别它们。 次结构中的任何位置。 使用自定义解决方案来创建预定生成。 可以创建 Visual Studio 预定生成，而不需要自定义解决方 案。 有一组可以开箱即用的签入策略。 新的签入策略可用于已破坏的 CI 生成。这样可以防止在 CI 生成被破坏时签入代码。 使用工具 converter.exe to 从 VSS 迁移 使用 Visual Studio 工具套件在 Team Foundation Server 到 Team Foundation Server。 和其他源代码管理系统（包括 VSS）之间生成转换和镜像 解决方案。 使用工作区映射定义要同步到本地计算 现在，Team Foundation Server 2008 允许映射掩蔽文件夹 机的一组文件。 下的文件夹或文件以及通配符，以便可以映射文件夹中的 所有文件，而不映射子文件夹。 使用 workspacemapping.xml 文件修改工 作区映射。 使用 TFS Power Tool 脱机工作。

使用 Team Foundation Server 2008 GUI 管理工作区映射， 不再使用 workspacemapping.xml。 使用 Visual Studio IDE 联机工作。

获得最新版本的文件以及将该文件签出 进行编辑是两个独立的源代码管理操作。 自定义预生成步骤，以便在引用的项目程 序集来自不同的团队项目时获得依赖项 使用 TFSBuild 命令行工具删除生成。

可以使用一个选项，在将文件签出进行编辑的同时自动获 得最新版本的文件。 在 VS GUI 中管理生成定义工作区模板，该模板具有标准 工作区的所有灵活性，包括映射来自多个团队项目的路径 使用 Visual Studio IDE 停止和删除生成。

其他资源 z

有关 Visual Studio 2008 Team Foundation Server 的详细信息，请参见“Microsoft Visual Studio 代 码名称“Orcas”概述白皮书”，网址为 http://go.microsoft.com/?linkid=6625887

指南：团队生成 索引 战略 z z z z z z

使用预定生成来产生常规生成。 使用连续集成 (CI) 生成来获取签入的快速反馈。 如果 CI 生成对生成服务器性能造成负面影响，可使用滚动式生成。 使用分支减少生成中断。 使用签入策略提高签入质量。 使用生成通知警报了解生成的完成时间。

分支 z z

在创建部分分支时使用新团队生成类型。 创建完整分支时，在 TFSBuild.proj 文件中修改解决方案路径。

签入策略 z z

使用签入策略提高签入质量。 使用签入策略将工作项与生成相关联。

连续集成生成 z z z

使用 CI 生成来获取签入的快速反馈。 如果 CI 生成对生成服务器性能造成负面影响，可使用滚动式生成。 确保滚动式生成的频率低于生成频率。

自定义 z z z z

使用自定义生成后步骤来生成安装程序项目。 使用 MS Build Toolkit Extras 来生成 Microsoft .NET 1.1 应用程序。 使用 TFSBuild.proj 修改生成。 使用自定义生成前步骤来生成与另一个团队项目有依赖关系的项目。

部署 z

在较大的团队中，将生成服务安装到单独的服务器。

性能 z z z z

使用增量式生成来改进性能。 避免生成中出现同步冗余文件夹。 使用工作区避免当执行团队生成时签出不需要的文件和项目。 考虑使用多个生成机器来改进性能。

项目 z z z z z

避免跨团队项目的依赖项。 使用项目引用而非文件引用。 为 Web 应用程序使用 Web 部署项目。 如果在较小的团队项目工作，请使用单解决方案战略。 如果在较大的团队项目（具有很多独立的子项目）工作，请使用分区解决方案战略。

z

使用在非常大的团队项目（需要很多独立的子项目）工作，请使用多解决方案战略。

预定生成 z

使用预定生成来产生常规生成。

测试驱动的开发 z z z

在各生成上运行代码分析。 在各生成上运行自动测试。 考虑当自动测试失败时将生成设置为失败。

工作项 z

使用工作项跟踪生成中断。

战略 z z z z z z

使用预定生成来产生常规生成。 使用 CI 生成来获取签入的快速反馈。 如果 CI 生成对生成服务器性能造成负面影响，可使用滚动式生成。 使用分支减少生成中断。 使用签入策略提高签入质量。 使用生成通知警报了解生成的完成时间。

使用预定生成来产生常规生成。 1.

使用预定生成按照预定的时间间隔产生常规生成。

通常，为您的测试团队和其他团队提供的生成必须可靠，并且可以以固定的时间频率使用，以便可 以及时收集生成的反馈。 Microsoft® Visual Studio® 2005 Team Foundation Server (TFS) 中的 Team Build 功能不支持通过用 户界面设置预定生成。但您可以使用 Microsoft Windows® Task Scheduler 运行 TFSBuild 命令行工 具以在预定的时间启动生成。 要创建预定生成 1.

2.

3.

创建如下 TFSBuild 命令行： TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>> 将该命令行放置在一个批处理文件中。 创建一个 Windows 任务计划，按照所需时间间隔运行这个批处理文件。

其他资源 z z

有关借助 Team Build 设置预定生成的详细信息，请参见本指南中的“第 9 章：借助 Team Build 设置预定生成”。 有关借助 TFS 设置预定生成的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中设置预定生成”。

使用连续集成生成来获取签入的快速反馈。 每次签入之后，应该使用 CI 生成为开发团队提供对任何中断更改以及生成质量的快速反馈。这有 助于开发团队快速修复生成问题，并且可以用作提高代码质量的工具。 尽管 Team Foundation Server 2005 不提供开箱即用的 CI 解决方案，但它为您提供实现自己的 CI

生成解决方案的框架。 有关使用 TFS 设置 CI 生成的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中设置连续集成生成”。这篇“如何”文章使用 Microsoft Visual Studio Team System (VSTS) 开发团队提供的解决方案。该解决方案安装一个 Web 服务，运行该服务的帐户具有对 TFS 服务器的访问权限。当发生特定事件时，Team Foundation Server 能够发送电子邮件消息或调用 Web 服务。CI 解决方案使用该事件机制注册 Web 服务的 CheckinEvent 事件，以便任何时候发生签入 时，此 Web 服务都会启动一个团队生成。

其他资源 z z z z z

有关详细信息，请参见本指南中的“第 8 章：使用 Team Build 设置连续集成生成”。 有关设置 CI 生成的详细信息，请参见本指南中的“如何：使用 Visual Studio Team Foundation Server 设置预定生成”。 有关如何使用 VSTS CI 解决方案的详细信息，请参见“使用 Team Foundation Build 连续集 成”，地址为：http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx 要下载 VSTS CI 解决方案 MSI，请访问： http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi 有关 TFS 中的敏捷开发和 CI 的详细信息，请参见“扩展 Team Foundation Server 来实现连续 集成”，地址为：http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx

如果 CI 生成对生成服务器性能造成负面影响，可使用滚动式生成 每次签入之后立即生成是最简单的 CI 战略，通常为您提供最快速的反馈。然而，如果签入的速度 足够快，拥塞生成服务器，则应使用滚动式生成方法，在指定签入次数或指定时间段后生成。要决 定是否使用滚动式生成，先确定以下几个方面： z z z

以分钟计算的团队生成长度 以分钟计算的平均签入频率 确定签入发生频率的时间窗口

如果生成的长度大于签入的平均频率，生成将连续运行，因为第一个生成要等到下一次签入发生时 才会完成，而这次签入又会启动另一次生成。如果在每个生成完成之前继续签入，这会影响生成服 务器的性能，并且将阻止启动其他生成（如预定生成）。查看签入发生频率的时间窗口并确定 CI 生 成是否会影响预定生成的发送以及是否影响其他重要的团队生成。

其他资源 z

有关详细信息，请参见本指南中的“第 8 章 – 使用 Team Build 设置连续集成生成”。

使用分支减少生成中断。 为了有助于避免生成中断，您应该对活动的开发使用“开发”分支，对集成生成使用“主要”分支。 下面是一个分支结构的示例，在创建了“开发”分支后，您的分支结构看起来可能就是这样： z Development – 开发分支 源代码 z Main – 集成分支 源代码 其他资产文件夹 在处理发布分支时，始终牢记以下建议： z

何时分支。如果您创建每日生成并且在生成稳定性和集成方面有问题，应该同时创建主要分支 和开发分支，以确保每日生成具有较大的预测能力。还应该考虑更严格的签入策略以提高签入

质量。 何时不分支。如果您只创建 CI 生成，或者可以预测每日生成已经非常稳定，则不需要额外进 行集成分支。 z 分支权限： 对于负责合并和集成的开发人员，“主要”分支权限应该是读/写权限，而对于其他人，则 是只读权限。 “开发”分支权限应该对每个人都是读/写权限。 z 分支中的生成频率： 在“主要”分支上每天生成。 在“开发”分支上 CI 生成。 z 关于分支的测试关注点： 在“主要”分支上执行集成、性能和安全测试。 在“开发”分支上执行功能和快速反馈测试。

z

将“主要”分支用作集成已经签入到开发分支中的更改的集结地。在“开发”分支中执行所有活动 的开发，然后将非中断的更改集成到“主要”分支中。

其他资源 z z z z z

有关定义分支和合并战略的详细信息，请参见本指南中的“第 5 章：定义分支和合并战略”。 有关分支与合并的简介，请参见“分支与合并入门”，地址为： http://msdn2.microsoft.com/en-us/library/aa730834(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx 有关合并的详细信息，请参见“如何：合并文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181428(VS.80).aspx 有关如何在 Visual Studio 2005 中进行分支与合并的详细信息，请参见“对 Team Foundation 源 代码管理进行分支和合并”，地址为： http://msdn2.microsoft.com/en-us/library/ms181423(VS.80).aspx

使用签入策略提高签入质量 应该将代码分析与测试策略相结合，来提高签入质量。例如，使用所提供的测试策略来确保指定测 试预先得到测试并已通过，之后再允许源代码签入 TFS 源代码管理。还可配置代码分析策略，确 保安全性、性能、可移植性、可维护性和可靠性规则通过，从而帮助确保代码满足某些质量标准。 除了强制编码标准和原则的策略之外，强制这种类型的签入策略可以针对特定的代码质量问题测试 代码。 要对团队项目强制代码分析签入策略，请右击“团队资源管理器”中的团队项目，指向“团队项目 设置”，然后单击“源代码管理”。单击“签入策略”选项卡，单击“添加”，然后选择并配置恰 当的策略。

其他资源 z z z z

有关创建和使用自定义签入策略的详细信息，请参见本指南中的“如何：为 TFS 创建自定义 签入策略详解”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx 要查看拒绝签入的选定模式的示例代码，请参见“拒绝某些模式的签入策略”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx 要查看对签入实施注释的示例代码，请参见“示例签入策略：确保注释非空”，地址为：

z

http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx 要了解如何注册新签入策略，请参见“我创建了一条新的签入策略！如何添加？”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx

使用生成通知警报了解生成的完成时间 要跟踪生成过程，可以创建在生成完成时创建警报，向您或其他人发送电子邮件消息。 这是非常重要的，因为它能加快各个团队之间的周转。例如，如果通过电子邮件通知测试团队生成 已完成，则他们可以启动他们的测试，而没有必要等待手动说明。

其他资源 z z

有关生成通知的详细信息，请参见“如何：接收生成通知电子邮件”，地址为： http://msdn2.microsoft.com/en-us/library/ms181725(VS.80).aspx 有关生成通知的进一步信息，请参见“如何：添加或编辑警报”，地址为： http://msdn2.microsoft.com/en-us/library/ms181335(VS.80).aspx

分支 z z

在创建部分分支时使用新团队生成类型。 创建完整分支时，在 TFSBuild.proj 文件中修改解决方案路径。

在创建部分分支时使用新团队生成类型 当创建包含团队项目中解决方案子集的分支时，为了成功生成可能需要创建新的生成类型。 有两种类型的部分分支： 1. 不包括任何生成类型的分支的部分分支。这将发生在团队项目内，并且将简化分支解决方案和 源文件，但不会将 TeamBuildTypes 文件夹中的任何文件分支到新的文件夹中。 2. 包括生成类型的分支的部分分支。这将发生在团队项目内，除了包含相关解决方案和源文件的 其他文件夹之外，它还对 TeamBuildTypes 子文件夹（即生成类型）中的某些文件进行分支。 如果您创建的部分分支不包括团队生成类型，则所有现有的团队生成将继续工作，但如果您向生成 分支，则需要创建一个新的团队生成类型。通过使用团队生成向导创建新的生成类型，以便在新分 支中生成代码。这些新的生成类型将指向新的分支位置，也可能指向必须包含在此生成中但未分支 的任何解决方案的父位置。 如果您创建的部分分支包括团队生成类型，则用此分支复制的生成类型将指向原来的父分支位置， 因此将不允许您生成新的分支。修改分支的生成类型，以便它们指向新的分支代码位置。

其他资源 z

有关如何更新生成类型的详细信息，请参见“如何：更新分支的团队项目上的生成类型”，地 址为：http://msdn2.microsoft.com/en-us/library/ms252500(VS.80).aspx

创建完整分支时，在 TFSBuild.proj 文件中修改解决方案路径 当您创建新的分支（包括团队生成类型）时，生成类型中的路径仍然指向以前的位置。为了使生成 在新的分支上工作，您必须更新生成类型项目文件中的路径，以便它们引用在分支操作之后创建的 新路径位置。 当您创建全部分支时，也会对生成类型进行分支。生成类型包含对原始源代码管理树中文件夹的引 用。要使这些生成类型引用分支文件夹，您必须编辑这些文件中的文件夹引用。

要执行更新，请从要修改的分支中签出生成类型，应用更新，然后提交对分支的更改。

其他资源 z

有关如何更新生成类型的详细信息，请参见“如何：更新分支的团队项目上的生成类型”，地 址为：http://msdn2.microsoft.com/en-us/library/ms252500(VS.80).aspx

签入策略 z z

使用签入策略提高签入质量。 使用签入策略将工作项与生成相关联。

使用签入策略提高签入质量 将代码分析与测试策略相结合，来提高签入质量。例如，使用所提供的测试策略来确保指定测试预 先得到测试并已通过，之后再允许源代码签入 TFS 源代码管理。还可配置代码分析策略，确保安 全性、性能、可移植性、可维护性和可靠性规则通过，从而帮助确保代码满足某些质量标准。 除了强制编码标准和原则的策略之外，强制这种类型的签入策略可以针对特定的代码质量问题测试 代码。

其他资源 z z z z z

有关创建和使用自定义签入策略的详细信息，请参见本指南中的“如何：为 TFS 创建自定义 签入策略详解”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx 要查看拒绝签入选定模式的示例代码，请参见“拒绝某些模式的签入策略”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/02/523125.aspx 要查看对签入实施注释的示例代码，请参见“示例签入策略：确保注释非空”，地址为： http://blogs.msdn.com/jmanning/archive/2006/01/21/515858.aspx 要了解如何注册新签入策略，请参见“我创建了一条新的签入策略！如何添加？”，地址为： http://blogs.msdn.com/jmanning/archive/2006/02/07/526778.aspx

使用签入策略将工作项与生成相关联 设置工作项签入策略，以强制开发人员将其签入与工作项关联。 如果生成中断，知道与该生成关联的变更集以及这些变更集关联的工作项是非常重要的。借助这种 了解，您可以确定负责签入更改代码的开发人员以及其工作的项目领域。 要使生成与一整套工作项关联，每次签入必须与一个工作项关联。这些签入表示为与生成关联的变 更集，并且可以从生成跟踪到变更集以及跟踪到工作项。

其他资源 z z

有关创建和使用自定义签入策略的详细信息，请参见本指南中的“如何：为 TFS 创建自定义 签入策略详解”。 要了解如何自定义签入策略，请参见“演练：自定义签入策略和签入说明”，地址为： http://msdn2.microsoft.com/en-us/library/ms181281(VS.80).aspx

连续集成生成

z z z

使用 CI 生成来获取签入的快速反馈。 如果 CI 生成对生成服务器性能造成负面影响，可使用滚动式生成。 确保滚动式生成的频率低于生成频率。

使用 CI 生成来获取签入的快速反馈 每次签入之后，应该使用连续集成生成为开发团队提供对任何中断的更改以及生成质量的快速反馈。 这有助于开发团队及时修复生成问题，并且可以用作提高代码质量的工具。 尽管 Visual Studio 2005 Team Foundation Server 不提供开箱即用的 CI 解决方案，但它为您提供实 现自己的 CI 生成解决方案的框架。 有关借助 TFS 设置 CI 生成的详细信息，请参见“如何：在 Visual Studio Team Foundation Server 中 设置连续集成生成。”这篇“如何”文章使用 VSTS 开发团队提供的解决方案。该解决方案安装一 个 Web 服务，运行该服务的帐户具有对 TFS 服务器的访问权限。当发生特定事件时，Team Foundation Server 能够发送电子邮件消息或调用 Web 服务。CI 解决方案使用该事件机制注册 Web 服务的 CheckinEvent 事件，以便任何时候发生签入时，此 Web 服务都会启动一个团队生成。

其他资源 z z z z z

有关 CI 生成的详细信息，请参见本指南中的“第 8 章 – 使用 Team Build 设置连续集成生 成”。 有关设置 CI 生成的详细信息，请参见本指南中的“如何：使用 Visual Studio Team Foundation Server 设置连续集成生成”。 有关如何使用 VSTS CI 解决方案的详细信息，请参见“使用 Team Foundation Build 连续集 成”，地址为：http://msdn2.microsoft.com/en-us/library/ms364045(VS.80).aspx 要下载 Visual Studio Team System CI 解决方案 MSI，请访问： http://download.microsoft.com/download/6/5/e/65e300ce-22fc-4988-97de-0e81d3de2482/ci.msi 有关 TFS 中的敏捷开发和 CI 的详细信息，请参见“扩展 Team Foundation Server 来实现连续 集成”，地址为：http://msdn.microsoft.com/msdnmag/issues/06/03/TeamSystem/default.aspx

如果 CI 生成对生成服务器性能造成负面影响，可使用滚动式生成 每次签入之后立即生成是最简单的 CI 战略，通常为您提供最快速的反馈。然而，如果签入的速度 足够快，拥塞生成服务器，则应使用滚动式生成方法，在指定签入次数或指定时间段后生成。要决 定是否使用滚动式生成，先确定以下几个方面： z z z

以分钟计算的团队生成长度 以分钟计算的平均签入频率 确定签入发生频率的时间窗口

如果生成的长度大于签入的平均频率，生成将连续运行，因为第一个生成要等到下一次签入发生时 才会完成，而这次签入又会启动另一次生成。如果在每个生成完成之前继续签入，这会影响生成服 务器的性能，并且将延迟其他生成（如预定生成）。查看签入发生频率的时间窗口并确定 CI 生成 是否会影响预定生成的发送以及是否影响其他重要的团队生成。

其他资源 z

有关设置 CI 生成的详细信息，请参见本指南中的“第 8 章 – 使用 Team Build 设置连续集 成生成”。

确保滚动式生成的频率低于生成频率 确定滚动式生成时间间隔对于确保有效的生成过程至关重要。如果滚动式生成的频率低于完成生成 所需的时间，则确保在滚动式生成的时间间隔内您的生成机器可用于其他生成类型。 要确定理想的滚动式生成时间间隔，用生成的长度除以签入的平均频率。例如，如果您拥有一个需 要 10 分钟的生成，并且您平均每 5 分钟签入一次，则应该设置签入时间间隔为两次签入，超时期 限为 10 分钟。这样有助于确保完成此生成之后，再进行下一个生成。如果您注意到生成服务器上 的负载过多，则可以增加这些值。

其他资源 z

有关 CI 生成的详细信息，请参见本指南中的“第 8 章 – 使用 Team Build 设置连续集成生 成”。

自定义 z z z z

使用自定义生成后步骤来生成安装程序项目。 使用 MS Build Toolkit Extras 来生成 Microsoft .NET 1.1 应用程序。 使用 TFSBuild.proj 修改生成。 使用自定义生成前步骤来生成与另一个团队项目有依赖关系的项目。

使用自定义生成后步骤来生成安装程序项目 由于默认情况下 Team Build 不支持设置项目，因此您应该使用自定义的生成后步骤以编译设置项 目并将二进制文件复制到生成的目标位置。

其他资源 z

有关详细信息，请参见“演练：配置 Team Foundation Build 以生成 Visual Studio 设置项目”， 地址为：http://msdn2.microsoft.com/en-us/library/ms404859(VS.80).aspx

使用 MS Build Toolkit Extras 来生成 Microsoft .NET 1.1 应用程序 Team Build 默认情况下不支持 .NET 1.1 应用程序。.NET 1.1 的工具套件 MSBuild Extras (MSBee) 允许 .NET 1.1 生成，但需要将项目和解决方案升级到 Visual Studio 2005。如果您无法升级到 Visual Studio 2005 项目和解决方案，则可以使用自定义的生成后步骤来编译 .NET 1.1 应用程序。

其他资源 z z

要下载 MSBee，请访问 http://www.codeplex.com/MSBee 有关创建自定义生成后步骤以编译 .NET 1.1 应用程序的详细信息，请参见 Nagaraju 的博客条 目，地址为：http://blogs.msdn.com/nagarajp/archive/2005/10/26/485368.aspx

使用 TFSBuild.proj 修改生成 要修改有关生成的信息，如生成服务器、目标位置或生成目录，请编辑 TFSBuild.proj 文件。 TFSBuild.proj 文件包含执行 Team Build 所需的大量信息。该信息包括生成位置以及是否生成应该 执行静态代码分析和单元测试。要修改生成，请编辑 TFSBuild.proj 文件。

编辑 TFSBuild.proj 文件 1.

2.

3.

从源代码管理签出该文件。 在文件中更新生成信息。 反向签入该文件，提交更改。

下次执行生成时，将使用修正后的生成数据。

其他资源 z

有关自定义 Team Foundation Build 的详细信息，请参见“自定义 Team Foundation Build”，地 址为：http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx

使用自定义生成前步骤来生成与另一个团队项目有依赖关系的项目 Team Build 不支持跨团队项目的生成解决方案。要支持该功能，必须自定义 TFSBuild.proj 文件以 从生成所依赖的其他项目中签出所需的代码。

其他资源 z z

有关详细信息，请参见“在团队生成中处理多个团队项目”，地址为： http://blogs.msdn.com/manishagarwal/archive/2005/12/22/506635.aspx 有关自定义 Team Foundation Build 的详细信息，请参见“自定义 Team Foundation Build”，地 址为：http://msdn2.microsoft.com/en-us/library/ms400688(VS.80).aspx

部署 z

在较大的团队中，将生成服务安装到单独的服务器。

在较大的团队中，将生成服务安装到单独的服务器 较大的 Team Build 可能需要很长时间并且会占用大量服务器资源。如果您在 Team TFS 服务器上 运行生成，将影响服务器的可靠性、性能以及伸缩性。 要提高生成的性能并减少应用程序层的负载，建议您在专用的生成服务器上运行生成。

其他资源 z

要下载“Team Foundation 安装指南”，或获得有关安装 TFS 和 Team Build 的详细信息，请 访问 http://www.microsoft.com/downloads/details.aspx?FamilyId=E54BF6FF-026B-43A4-ADE4-A69038 8F310E&displaylang=en

性能 z z z z

使用增量式生成来改进性能。 避免生成中出现同步冗余文件夹。 使用工作区避免当执行团队生成时签出不需要的文件和项目 考虑使用多个生成机器来改进性能。

使用增量式生成来改进性能 默认情况下，Team Build 清除其所使用的目录来执行生成，然后签出生成所需的完整的源代码树。 Team Build 还删除和重新初始化用于签出生成的源代码的工作区。要提高性能，您可以设置 Team Build 仅获得自从上次 Team Build 更改之后的源代码。 如果生成所需的源代码数量比较大，并且生成服务器远离 TFS 服务器，则签出源代码可能需要执 行很长时间。这种情况下，您应该考虑使用增量式生成。要执行增量式生成，您需要设置

TFSBuild.proj 文件中的几个应该为 true 的值。您需要： z 使 Team Build 停止清理本地生成文件夹和源文件夹。 z 使 Team Build 停止重新创建用于生成的工作区。 z 将 Team Build 配置为仅从源代码管理中获得更改的源代码。 执行增量式生成 1.

2.

3.

创建一个新的生成类型以表示增量式生成。 签出与刚刚创建的增量式生成类型关联的 TFSBuild.proj 文件以便进行编辑。 在 TFSBuild.proj 中，将以下 <PropertyGroup> 部分添加到结尾的 </project> 元素之前： <PropertyGroup> <SkipClean>true</SkipClean> <SkipInitializeWorkspace>true</SkipInitializeWorkspace> <ForceGet>false</ForceGet> </ PropertyGroup>

这些设置完成以下工作： z SkipClean。将 SkipClean 设置为 true 确保生成不会清除本地生成和源文件夹。 z SkipInitializeWorkspace。将 SkipInitializeWorkspace 设置为 true 确保生成将现有工作区保 留在生成机器的适当位置。 z ForceGet。将 ForceGet 设置为 false 确保生成只获得更新的代码，而不是获得工作区的所有 代码。

其他资源 1.

2.

有关详细信息，请参见本指南中的“实践总览 – Team Build”。 有关配置增量式生成的详细信息，请参见“如何：将 Team Foundation Build 配置为增量生成”， 地址为：http://msdn2.microsoft.com/en-us/library/aa833876(VS.80).aspx

避免生成中出现同步冗余文件夹 您应该缩小不需要作为生成的一部分的工作区映射或掩蔽文件夹。 当执行 Team Build 时，服务器从源代码管理中检索所需的所有文件。由用于创建 Team Build Type 的工作区对检索的文件进行定义。可能不需要映射到工作区中的某些文件。您可以更改工作区定义 以减少包含的文件夹，或者可以掩蔽不需要的文件，以便它们不会作为生成的一部分被检索到。 例如，新项目的默认映射是 $/TeamProject。如果所有源文件都位于 $/TeamProject/foo/bar/foobar/sources 下，则应该只映射该目录。 要掩蔽工作区映射下的文件，可以编辑 WorkspaceMapping.xml 文件，该文件是在创建 Team Build Type 时创建的，并且用来定义执行生成时检索的文件夹。作为生成的一部分，可以掩蔽不需要的文 件和文件夹。首选掩蔽文件夹，因为掩蔽各个文件可能会产生维护费用。

掩蔽文件夹 1.

2.

3.

从源代码管理签出 WorkspaceMapping.xml。 为该文件添加恰当的掩蔽项。 签入 WorkspaceMapping.xml。

以下示例确保在团队生成期间不会从源代码管理中检索到文档文件夹： <Mappings> <InternalMapping ServerItem="$/MyTeamProject" LocalItem="c:\projects\teamproject”

Type="Map" /> <InternalMapping ServerItem="$/MyTeamProject/documentation" Type="Cloak" /> </Mappings>

其他资源 z z z

有关掩蔽工作区中的文件夹的详细信息，请参见“如何：掩蔽或取消掩蔽工作区中的文件夹”， 地址为：http://msdn2.microsoft.com/en-us/library/ms181378(VS.80).aspx 有关使 Team Build 忽略文件夹的详细信息，请参见“如何使‘Team Build’跳过获取特定文件 夹？”，地址为：http://blogs.msdn.com/manishagarwal/archive/2005/10/13/480584.aspx 有关 WorkspaceMapping 体系结构的详细信息，请参见“WorkspaceMapping.xml 文件的体系结 构”，地址为： http://blogs.msdn.com/buckh/archive/2007/02/28/schema-for-the-workspacemapping-xml-file.aspx

使用工作区避免当执行团队生成时签出不需要的文件和项目 Team Build 签出源代码，以便执行生成。如果项目具有大量源代码树，则签出源代码可能非常耗时。 如果您仅生成团队项目的一部分，则应该确保仅签出所需的源代码。 如果您拥有较大的团队项目，则它将包含多个 Visual Studio 解决方案，每个方案都用于生成团队项 目中的一个独立部分。当创建 Team Build Type 时，应该指定 Team Build 将使用的解决方案。如 果指定了解决方案文件，而没有指定工作区，则 Team Build 先将签出团队项目中的所有源代码， 然后再执行生成。 要仅签出所需的源代码，必须首先定义工作区。创建 Team Build Type 之前，应该首先定义工作区 并且仅将要生成的解决方案映射到该工作区。定义 Team Build Type 时，选择已经定义的工作区， 然后选择解决方案。这样，将只签出该工作区中已定义的源代码。

其他资源 z z

有关创建 Team Build Type 的详细信息，请参见“演练：在 Team Foundation Build 中创建生成 类型”，地址为：http://msdn2.microsoft.com/en-us/library/ms181286(VS.80).aspx 有关 Team Build 签出工作区中所有源代码的原因的详细信息，请参见“尽管我只选择了解决 方案的一个子集，但为什么 Team Build 同步所有源代码？”，地址为： http://blogs.msdn.com/anutthara/archive/2005/12/07/500923.aspx

考虑使用多个生成机器来改进性能 如果您拥有多个生成类型，而所有这些类型都在一个生成服务器上执行，则服务器可能会不堪重负。 在这种情况下，应该考虑在不同的生成服务器上执行不同的生成类型。 一个生成可能要花很长时间执行，尤其在此生成是针对大型项目时更是如此。如果您使用 CI 或时 常发生的预定生成，则生成服务器可能无法跟上生成的生成数量。 您可以安装多个生成服务器，以将负载分布到不同服务器之间。为每个服务器分配不同的生成类型 以使生成负载比较平均。

其他资源 z

有关详细信息，请参见本指南中的“第 7 章 – 介绍 Team Build”。

项目

z z z z z z

避免跨团队项目的依赖项。 使用项目引用而非文件引用。 为 Web 应用程序使用 Web 部署项目。 如果在较小的团队项目工作，请使用单解决方案战略。 如果在较大的团队项目（具有很多独立的子项目）工作，请使用分区解决方案战略。 使用在非常大的团队项目（需要很多独立的子项目）工作，请使用多解决方案战略。

避免跨团队项目的依赖项 通常，您应该避免跨团队项目的依赖项，并尝试保留同一团队项目下的所有相关/依赖的解决方案/ 项目。这会减少对生成脚本自定义的需要。如果您有依赖项，请使用项目引用来定义它，或者将共 享项目中的依赖项分支到您的项目中。应避免使用文件引用，因为文件引用管理起来更困难。

其他资源 z z z

有关创建工作区的详细信息，请参见“如何：创建工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms181384(VS.80).aspx 有关编辑工作区的详细信息，请参见“如何：编辑工作区”，地址为： http://msdn2.microsoft.com/en-us/library/ms245466(VS.80).aspx 有关分支的详细信息，请参见“如何：分支文件和文件夹”，地址为： http://msdn2.microsoft.com/en-us/library/ms181425(VS.80).aspx

使用项目引用而非文件引用 如果您需要在用一个 Visual Studio 解决方案中引用其他程序集，则应该使用 Visual Studio 项目引 用。通过使用项目引用，您可以使 Visual Studio 自动为您执行一些事项，如保持生成配置同步（调 试/发布）、跟踪版本控制以及程序集版本更改时重新生成所需的程序集。

其他资源 z

有关项目引用的详细信息，请参见“项目引用”，地址为： http://msdn2.microsoft.com/en-us/library/ez524kew(VS.80).aspx

为 Web 应用程序使用 Web 部署项目 Web 部署项目与 Visual Studio 网站项目或 Web 应用程序项目相关联。它们允许您管理生成设置 以及 ASP.NET Web 应用程序通用的各种其他设置。例如，部署应用程序可以使您轻松访问 Web.config、连接字符串以及虚拟目录，并且允许您将已编译的 Web 应用程序轻松部署到托管服务 器。

其他资源 z

有关详细信息，请参见“ Visual Studio 2005 Web 部署项目”，地址为： http://msdn2.microsoft.com/en-us/asp.net/aa336619.aspx

如果在较小的团队项目工作，请使用单解决方案战略 如果您在一个小型团队上工作，那么可考虑使用单独一个 Visual Studio 解决方案来包容所有项目。 这种结构能简化开发，因为在打开解决方案时，所有代码都是可用的。这种战略也简化了引用的设 置，原因在于所有引用都处于该解决方案内的项目之间。您可能仍然需要使用文件引用来引用您的 解决方案之外的第三方程序集，如购买的组件。

其他资源 z

有关详细信息，请参见本指南的“第 3 章 – 在源代码管理中设计项目和解决方案的结构”。

如果在较大的团队项目（具有很多独立的子项目）工作，请使用分区解决 方案战略 如果您在较大的团队工作，请考虑使用多个解决方案，每个方案代表应用程序中的一个子系统。开 发人员可以使用这些解决方案在较小的系统部分上工作，而不需要跨所有项目加载所有代码。您应 该设置您的解决方案结构，以便将具有依赖项的任何项目组合在一起。这使您能够使用项目引用而 非文件引用。如果您想使用它来生成整个应用程序，请考虑创建包含所有项目的主解决方案文件。

注意：如果您使用 Team Build（它依赖于 MSBuild）生成，则可以创建不包括所有引用的项目的 解决方案结构。只要首先已经生成了整个解决方案，并从每个解决方案中生成二进制输出，那么 MSBuild 将能够遵循超出您的解决方案范围之外的项目引用并成功生成。采用这种方法创建的解决 方案将不能从 Visual Studio 生成命令中生成，但只能使用 Team Build 和 MSBuild。

其他资源 z

有关详细信息，请参见本指南的“第 3 章 – 在源代码管理中设计项目和解决方案的结构”。

使用在非常大的团队项目（需要很多独立的子项目）工作，请使用多解决 方案战略 如果您在非常大的解决方案（需要很多项目）上工作，则可能会与解决方案的伸缩性限制发生冲突。 在这种情况下，应该将您的应用程序分为多个解决方案，而不是为整个应用程序创建一个主解决方 案，因为每个解决方案内的所有引用都是项目引用。对每个解决方案之外的项目的引用（例如，另 一个子解决方案中的第三方库或项目的引用）为文件引用。这就意味着，不存在任何“主”解决方 案。相反，必须使用了解生成解决方案顺序的脚本。与多解决方案结构相关联的维护任务之一就是 确保开发人员不会无意中在解决方案间创建循环引用。这种结构需要复杂的生成脚本，以及依赖项 关系的显式映射。在这种结构中，应用程序不可能完全在 Visual Studio 内生成。与此不同，您可是 直接使用 TFS Team Build 或 MSBuild。

其他资源 z

有关详细信息，请参见本指南的“第 3 章 – 在源代码管理中设计项目和解决方案的结构”。

预定生成 z

使用预定生成来产生常规生成。

使用预定生成来产生常规生成。 应该使用预定生成按照预定的时间间隔产生常规生成。 通常，为您的测试团队和其他团队提供的生成必须可靠，并且可以以固定的时间频率使用，以便及 时收集生成的反馈。 尽管 TFS 中的 Team Build 功能不支持来自用户界面的预定生成，但您可以使用 Microsoft Windows Task Scheduler 运行 TFSBuild 命令工具，以按预定的时间启动生成。

要创建预定生成 1.

2.

3.

创建如下 TFSBuild 命令行： TfsBuild start <<TeamFoundationServer>> <<TeamProject>> <<BuildTypeName>> 将该命令行放置在一个批处理文件中。 创建一个 Windows 任务计划，按照所需时间间隔运行这个批处理文件。

其他资源 z z

有关详细信息，请参见本指南中的“第 9 章 – 使用 Team Build 设置预定生成”。 有关设置预定生成的详细信息，请参见本指南中的“如何：使用 Visual Studio Team Foundation Server 设置预定生成”。

测试驱动的开发 z z z

在各生成上运行代码分析。 在各生成上运行自动测试。 考虑当自动测试失败时将生成设置为失败。

在各生成上运行代码分析 使用代码分析作为生成的一部分，以提高生成质量。还可以在生成中配置代码分析步骤，以帮助确 保代码满足某些质量标准，从而确保能通过安全性、性能、可移植性、可维护性和可靠性规则。 要打开生成类型的代码分析，可以在创建新的 Team Build Type 时，选中“Team Build Type”向导 中的“代码分析”复选框，也可以在创建生成类型之后，修改 TFSBuild.proj 文件。

要在 TFSBuild.proj 文件中启用代码分析 z z

如果您让所有项目都运行代码分析，则无论项目设置如何，请将 <RunCodeAnalysis> 标记更 改为 Always。 如果您想在每个项目上根据项目设置来运行代码分析，请将 <RunCodeAnalysis> 标记更改为 Default。

其他资源 z z

有关作为生成的一部分的自动代码分析的详细信息，请参见本指南中的“如何：在 Visual Studio Team Foundation Server 中使用 Team Build 自动运行代码分析”。 有关代码分析工具的详细信息，请参见“代码分析工具使用准则”，地址为： http://msdn2.microsoft.com/en-us/library/ms182023(VS.80).aspx

在各生成上运行自动测试 每次生成之后，运行自动测试以自动获得有关生成质量的反馈。要创建与生成关联的测试列表，必 须安装 Visual Studio Test Edition 或 Visual Studio Team Suite。为在生成服务器上运行自动测试， 该生成服务器上必须安装有 Visual Studio Developer Edition、Visual Studio Test Edition 或 Visual Studio Team Suite。 要将自动测试作为 Team Build 过程的一部分运行 1.

2.

3.

4.

5.

6.

7.

创建您希望为该生成运行的一个或多个自动测试。 使用测试管理器创建测试列表。 使用测试管理器将测试分组为新测试列表，只需将测试视图中的测试拖放到测试管理器的测试 列表中即可。 创建一个新的 Team Build Type。 选中该复选框来运行自动测试。 选择要创建测试和测试列表的测试项目。 选中您希望运行的测试列表。

其他资源 z

有关自动运行版本验证测试的详细信息，请参见“如何：配置和运行生成验证测试 (BVT)”， 地址为：http://msdn2.microsoft.com/en-us/library/ms182465(VS.80).aspx

z

有关如何在没有 Visual Studio Test Edition 或 VSMDI 文件的条件下运行自动生成测试的 详细信息，请参见“如何在没有测试元数据文件和测试列表（.vsmdi 文件）的生成中运行 测试”，地址为： http://blogs.msdn.com/buckh/archive/2006/11/04/how-to-run-tests-without-test-metadata-files-and-tes t-lists-vsmdi-files.aspx

考虑当自动测试失败时将生成设置为失败 生成由于编译错误失败时，会创建一个工作项来跟踪失败，该生成被标记为失败。然而，如果一次 自动测试失败，生成并不会失败。测试失败将转换成一个警告，生成继续。 您可能希望在关联的自动测试失败时使生成失败。还可能希望自动生成一个工作项来跟踪测试失败。

要在测试失败时使生成失败 1.

2.

3.

4.

5.

打开 Program Files\MSBuild\Microsoft\VisualStudio\v8.0\TeamBuild 中的 Microsoft.TeamFoundation.Build.targets 文件。 签出进行编辑并打开希望在测试失败时失败的 Team Build Type 的 TFSBuild.proj 文件。 将 RunTestWithConfiguration 目标从 Microsoft.TeamFoundation.Build.targets 复制到 TFSBuild.proj 文件结尾，位于结尾的 </Project> 标记之前。 将 ContinueOnError 属性从 true 更改为 false。 注意：将有两项测试工具任务。修改端对端任务，以便仅修改生成服务器上生成的行为。当生 成位于开发人员的桌面上时，使用桌面生成任务。 如果您想在生成失败时创建一个工作项，请通过在结尾的 </Target> 标记之前添加 OnError 元素，修改 RunTestWithConfiguration。OnError 元素应类似于如下形式： <OnError ExecuteTargets="CreateWorkItem;"/>

或者，如果您想在测试失败时，使所有 Team Build Type 都失败，则可以直接修改 Microsoft.TeamFoundation.Build.targets。此更改将修改所有 Team Build Type 的行为。 上面建议的解决方案实施起来非常简单，但不能保证继续为将来版本的 Visual Studio 工作。如果您 想实施一个在升级之后保证继续工作的解决方案，请参见 Aaron Hallberg 的博客条目“在 Team Build 中确定测试是否通过”，地址为： http://blogs.msdn.com/aaronhallberg/archive/2006/09/21/determining-whether-tests-passed-in-team-build.a spx

其他资源 z z

有关设置生成以在测试失败时创建一个工作项的详细信息，请参见“在 TeamBuild 中创建测试 失败的工作项”，地址为：http://blogs.msdn.com/nagarajp/archive/2005/10/14/481290.aspx 有关在 Visual Studio 升级后必须继续工作的解决方案的详细信息，请参见“在 Team Build 中确定测试是否通过”，地址为： http://blogs.msdn.com/aaronhallberg/archive/2006/09/21/determining-whether-tests-passed-in-team-b uild.aspx

工作项 z

使用工作项跟踪生成中断。

使用工作项跟踪生成中断 如果 Team Build 失败，系统会自动创建一个工作项来跟踪该失败。默认情况下，工作项将被分配 为“活动”并且标题将告诉您生成已失败。您应该将此工作项指定给负责的开发人员或生成管理员， 以便修复此生成并解决此问题。

TFSBuild.proj 中的生成任务定义该工作项如下： <!-- Create WorkItem for build failure --> <CreateNewWorkItem BuildId="$(BuildNumber)" Description="$(WorkItemDescription)" TeamProject="$(TeamProject)" TeamFoundationServerUrl="$(TeamFoundationServerUrl)" Title="$(WorkItemTitle)" WorkItemFieldValues="$(WorkItemFieldValues)" WorkItemType="$(WorkItemType)" ContinueOnError="true" /> 如果您想自定义创建的工作项（例如，将其分配给特定的开发人员或设置安全性和优先级），则可 以修改 WorkItemFieldValues 字段。

其他资源 z

有关自定义生成失败工作项的详细信息，请参见“Team Foundation Build 任务”，地址为： http://msdn2.microsoft.com/en-us/library/ms243778(vs.80).aspx

生成资源 z

有关 Team Build 的常规详细信息，请参见“Team Foundation Build 概述”，地址为： http://msdn2.microsoft.com/en-us/library/ms181710(VS.80).aspx