【IT168 技术文章】
注本文档于产品投入生产之前编写，因此您可能会发现这里所包含的细节与发布的产品有不一致的地方。文中的信息均依据撰写本文时的产品状况，仅供您在规划时参考。如有更改，恕不另行通知。Microsoft 拥有本文档中的主题所涉及的专利、专利应用程序、商标、版权或其他的知识产权。除非 Microsoft 以任何书面许可协议明确提供，向您提供本文档并没给予您使用这些专利、商标、版权或其他知识产权的任何许可证。
简介
您是在一个开发企业级应用程序的团队中工作吗？您是将您的应用程序部署到 Microsoft .NET 环境吗？如果这样，则您知道，设计、开发、交付和维护这些应用程序的复杂性要求您在整个产品开发周期内都要跟踪需求。Visual Studio 2005 Team System 是一个应对这些需求的软件开发生命周期 (SDLC) 工具。有关 Team System 的详细信息，请参见 Visual Studio 2005 Team System：概述。
Visual Studio 2005 Team System 是适用于软件架构师、开发人员、测试人员以及其他团队成员（例如，项目经理、支持人员和文档编写人员等）的整套软件开发工具。
简要讨论软件配置管理 (SCM)
软件配置管理 (SCM) 在软件开发生命周期 (SDLC) 中起着重要的作用。SCM 是企业用来完成以下工作的做法、策略和流程的集合：
. 控制对源文件的访问
. 创建和管理工作项
. 生成产品版本
. 管理产品版本
有效的 SCM 策略就像一只好的鞋子 — 它符合您的项目和团队随时间而变化的独特需求；不能简单地与其他公司共享；而且一旦就绪，就 很容易忘记，直到您缺少它无法进行工作为止。
有效的 SCM 策略使得您的团队可以：同时在多个版本的产品上工作，将更改从一个版本移植到另一个版本，同时在同一个文件中工作而不丢失数据，并且可以不费力气地将代码缺陷追踪回其根源及创建者。
简化这些更改管理任务的 SCM 工具分为三类：
. 源代码管理
. 工作项跟踪
. 审核和报告
SCM 工具
软件工具供应商为您的团队提供了可以用来实现更改管理策略的大量工具。这些工具可分为三类：独立的 SCM 应用程序、集成更改管理工具包，以及 SDLC 工具套件。
独立的 SCM 应用程序不与其他的 SCM 应用程序进行通信。为此，开发团队成员很难将分配给他们的配置项（包括源文件、工作项、版本、项目等）与其他类型的配置项相关联。该问题最常见的表现就是开发人员不能将工作项与源文件或 changeset 相关联。
另外，集成更改管理工具包使得团队成员能够将工作项与源代码管理的文件相关联。有些工具（例如，Visual Studio Team Foundation）使得开发人员能够在集成开发环境 (IDE) 中执行基本的更改管理任务，同时还为在外部工作或需要执行更多扩展更改管理任务的团队成员提供独立的接口。
最后，SDLC 工具套件使得团队成员能够将工作项与源代码管理的文件相关联。SDLC 工具套件代表的是一种软件配置管理的综合方法，并且常常会给开发生命周期的各个方面强加 SCM 规则。它们通常包括适用于软件开发团队各个功能区的专用工具和功能，从体系结构到开发到文档，以及诸如工作项跟踪和完成重大更改管理任务的源代码管理应用程序等工具。
SCM 的传统方法
传统上，团队被迫在 SDLC 和软件配置管理的两种方法中进行选择：即席方法与命令和控制 方法。
特殊方法
针对 SCM 采用特殊方法的团队通常以增量的方式进行，他们一边通过试错进行学习，一边填补他们的 SCM 策略中的漏洞。他们常常混合使用独立工具和开发环境插件（例如，Visual SourceSafe），这为 Visual Studio 开发环境提供了集成源代码管理服务。
特殊 SCM 的优点
. 初始成本低。
. 灵活性：参与人员并没感到过程或工具有太多的约束，因为两者都可以根据他们的偏好和需求进行调整。
特殊 SCM 的缺点
. 总拥有成本 (TCO) 高：工具和过程必须不断地简化、改进或替换。新员工要花很长时间来掌握工具或流程。
. 沟通困难：SCM 流程将中断工作流。开发人员事先或许不会就可能中断版本或测试用例的更改而与测试人员进行交流，因为进行更改时，他们的 SCM 工具不允许或不鼓励他们这样做。
. 缺乏可预见性：由于缺少准确的报告功能，项目经理发现要确定某版本在某一时间点的准确状态是很难的。
. 延迟发布和服务软件包：开发人员发现事先就潜在的中断更改与测试人员进行足够的交流是很困难的，因为进行更改时，他们的 SCM 工具不允许或不鼓励他们这样做。缺乏这种跨功能的交流会导致以后出现中断更改，这种更改会迫使延迟（落后）发布，或者在某些情况下，迫使
. 工作组放慢日程表并随后创建缺陷（错误）服务软件包，这些缺陷在发布之前进行修复也许更容易些。
. 缺乏可重复性：由于缺乏报告功能以及没有将缺陷跟踪和源代码管理系统进行集成，因此很难跟踪到错误的根源。
命令和控制方法
端到端的软件配置管理 SDLC 解决方案有助于（在某些情况下）强迫项目参与人员按照 SCM 规定或团队的特定规则来完成开发任务。端到端生命周期管理工具可在开发环境内或作为独立的应用程序使用。最重要的是，通过使参与人员能更轻松地将分配给他们的配置项目与其他配置项关联起来，SDLC 解决方案改善了参与人员之间的沟通。传统上，这类解决方案成本很高，这意味着它们通常由企业开发团队和 ISV 实现。
命令和控制 SCM 方法的优点
. 良好的跨功能沟通：例如，项目参与人员可以订阅和接收电子邮件通知，通告他们重要的更改。这使得他们能够更有效地合作并完成协作项目。
. 可预见性：利用健壮的报告、审核、事件通知和集成的更改管理工具，项目经理人可以确定某一版本在某一时间点的准确状态。因此，发布日期很容易预测，并且发布后不会频繁需要服务软件包。
. 可重复性：工作项跟踪和源代码管理系统之间的集成使得跟踪错误的根源更容易。反过来，团队可以更安心地在产品的两个或更多版本上并行工作，并知道当版本之间出现差异时可以很容易地识别出来并进行协调。
命令和控制 SCM 方法的缺点
个别参与人员常常会抵制命令和控制 SCM 解决方案。
. 复杂性和成本：新员工的学习时间较长。设置和维护 SDLC 工具包的成本较高。实现集成的 SCM 系统要花费多达一年的时间，还需要团队雇用专门的 SCM 顾问来保持系统平稳运行。
. 灵活性差：与特殊解决方案不同，常常很难修改 SDLC 工具包以适应团队的特定需求。即使有可能这样做，它也将如此复杂，或者需要详细的 SCM 软件知识，以致团队必须雇用 SCM 专家来做这项工作。
Microsoft 的 SCM 方法
Visual Studio 2005 Team System 是灵活的、端到端的软件开发生命周期 (SDLC) 工具套件，它将 Visual Studio 的工作效率和创新潜能与进行软件生命周期管理的面向过程解决方案的可预见性和可重复性结合起来。Team System 合并了架构师、开发人员、测试人员、项目经理、文档编写人员和其他项目参与人员使用的工具。
Team System 的核心是集成的更改管理组件，它不引人注目地将 SCM 流程和团队的特定需求插入到了开发人员的日常工作流中。这些组件是：
. 工作项跟踪
. 源代码管理
. 策略支持
. 通知和报告生成功能
. 这些组件统称为 Visual Studio Team Foundation。
集成工作项跟踪和源代码管理
通过支持项目参与人员将工作项与其他类型的配置项或构件 关联起来，Visual Studio Team Foundation 扫清了源代码管理、工作项跟踪和版本管理之间的障碍。
Visual Studio Team Foundation 中有四种类型的构件：work items、source files、changesets，它们是进行签入操作的产品，此外还有 builds。工作项可包含到其他三种工件类型的链接。
将源文件链接到工作项
当修改工作项（例如，错误）时，您可能想要将它和源代码管理文件与工作项关联起来。如果您正在处理和签入的代码更正了错误中μ?ò???问题，您将希望将工作项连接到源文件上。这将错误链接到每个人都可以看到的更正代码上。对于其他任何一种工作项类型来说，代码与其交互的方式可能不同。在所有情况下，将它们连接在一起将可以为您的团队节约时间和精力。
将工作项链接到 Changesets
当您将多个文件的修订签入到源代码管理中时，就会在版本控制数据库中创建一个具有唯一标识符的新 changeset 构件，以包含修订和相关的元数据。您在 checkin 过程中选择的、与 changeset 关联的任何工作项随后都要进行修改，以回指这个新的 changeset。因而，该工作项就链接到了 changeset。
将版本链接到工作项
当您发现版本中的一个代码缺陷或工作项在版本中已经可用时，工作项和版本之间就有了内在关系。Visual Studio Team Foundation 将这种关系表示为存储在工作项中的一个链接。
Checkin 策略
使用 Visual Studio Team Foundation，公文包项目管理员可以将自定义或样本策略与 checkins 和其他事件关联起来。策略 是一种指导原则，它提供操作环境或强烈建议执行 SCM 操作之前要满足某些条件。
最常见的策略类型是 checkin 策略。在将一组待定更改签入到数据库之前，checkin 策略验证开发人员的更改是否符合企业的要求。当开发人员试图签入违反团队策略的待定更改时，会引发一个策略警告。
注 项目参与人员可以忽略策略警告。但是，当忽略策略警告时，项目管理员可以通过电子邮件请求通知。
您可以将策略警告看作是 Visual Studio 中版本错误的扩展。策略警告是团队特定的源代码管理综合指导原则，它提醒开发人员在将他们的待定更改签入之前执行一些操作。策略是一种提示，而不是指令。
生成报告
使用 Visual Studio Team Foundation，您可以生成单个工作项的进程报告，跟踪它直至完成，甚至可以查看与其解析相关的代码。开发人员可以将代码 checkin 和需要它的工作项和构建关联起来。如果工作项是从失败的测试结果生成的，那么 Team Foundation 功能将使您能够查看测试过程中出现了什么问题，向下搜索修复它的代码，并验证该修复是否能使测试成功。您将不再需要记住或写下错误的数量和代码 checkin 日期以查看是哪个修复最终修复了错误 — 一切工作都将在一个地方完成。
工作项跟踪功能
工作项是分配给您的产品团队成员的工作单元。工作项可由有适当权限的人员修改和再分配。可以用报告跟踪它们，用 Microsoft Project 安排日程，其列表可以输出到 Excel 中以做更多的分析。团队可以用自己的字段、窗体、状态转换和规则来定义他们自己的工作项类型。开发人员使用工作项划分他们的工作的优先级、记录依赖项，并在某项修复完成或需要其他操作时通知测试人员和其他团队成员。架构师、设计人员、测试人员、技术编写人员、本地化人员和可用性工程师可以创建和分配工作项，以便记录项目配置项的问题并跟踪完成他们目标的进度。Team Foundation Server 附带的常见工作项类型示例包括：错误、需求、任务、风险和进度。
创建工作项查询
当您跟踪问题时，可以从许多地方开始，但最可能的是创建为您提供所需要的工作项的工作项查询。从工作项查询生成器，您可以创建包括或不包括数据库中任何字段以及该字段所有可能值的工作项查询。您还可以搜索已分配给您的项目的任何错误。然后，如果您是“项目管理员”组建的安全团队的一部分，那么您就可以将错误分配给需要修复它们的开发人员。您可以搜索分配给您的任何工作项。您可以搜索已更改状态的工作项，例如，那些现在已解决或最近已关闭的工作项。当您这样做了，您可以刷新您的查询并查看您所做的事情是如何更改结果列表的 — 所要做的只是单击一个按钮。
通过解析和测试处理检测到的错误
每个项目参与人员都需要知道如何通过解析和测试处理检测到的错误。团队中的每个人都可能发现和进入团队“公文包项目”中的错误，这取决于您的团队指导原则的制订方式。通常，创建错误的人负责验证该项目中是否已经不存在该错误。取决于团队的配置和需求，您的项目管理员可能会组建特殊团队来优先考虑没有分配给某个特定的人所引入的错误。该团队负责将错误分配给最合适的人以进行进一步的操作，负责“通过设计”来解决错误，或确定某一项是否满足“错误吧 (bug bar)”或里程碑指导原则。
如果将错误分配给一个开发人员来进行修复，那么这个开发人员可以按照所提供的步骤进行修复，请求重新产生错误的步骤说明，与测试人员一起确定根本原因，查找由其他团队成员修复的复制错误，查找并链接到相关的错误，等等。当开发人员完成工作时，该错误就分配给测试人员进行修复测试，要么接受它已得到修复，要么退回该错误以进行额外的工作。而且按照团队的指导原则，该错误由负责关闭的人员或团队关闭。
根据您的团队需要调整工作项窗体
作为公文包项目管理员，您可以接受 Visual Studio Team Foundation 为您包括的窗体，也可以自定义窗体以满足团队需求。例如，您可以自定义您的团队成员可以看到的字段名，以及所有字段名在工作项窗体上的位置。
为您的窗体设置规则和权限
您不仅可定义谁能查看您的层次结构，还可通过使用工具包附带的工作项类型来自定义您自己的窗体。如果选择不使用工具包附带的工作项类型，您就可创建、导入、导出和更新工作项类型。为了增加安全性，还可能控制各个团队成员查看您的层次结构，并相应地分配项目和层次结构权限。最后一步，您可以为用户释放窗体来结束。
管理服务器操作
作为操作管理员，您管理着服务器端与用户和数据的所有交互。您可以监视服务器并管理告警、备份和恢复项目数据库、计划服务器的容量、管理服务器修补程序以控制来自 Microsoft 的安全警告、设置并升级基于服务器的新产品推广、检查数据库的一致性并纠正问题、诊断性能问题，以及分配服务器端和数据库的权限。
