适用于:
Microsoft Visual Studio? 2005 Team System
摘要:本文描述 Visual Studio 2005 Team System 中用于企业级源代码管理、工作项管理以及报告的集成更改管理组件。
注本文档于产品投入生产之前编写,因此您可能会发现这里所包含的细节与发布的产品有不一致的地方。文中的信息均依据撰写本文时的产品状况,仅供您在规划时参考。如有更改,恕不另行通知。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 的安全警告、设置并升级基于服务器的新产品推广、检查数据库的一致性并纠正问题、诊断性能问题,以及分配服务器端和数据库的权限。
通过 Web 接口跟踪工作项
最后,在没有完全安装 Visual Studio 的情况下,您可以利用工作项跟踪工具包的 Web 接口外壳来跟踪工作项。但如果没有服务器端的全部信息或没有完全安装
Visual Studio 产品,您仍然可以监视和维护工作项的跟踪信息。
源代码管理
为了确保您的软件开发项目能够成功协作,您可以做的最简单的一件事情就是将团队共享的开发资源置于源代码管理之下。源代码管理保护团队资源免遭意外删除、保护个别更改免遭盲目或无意地重写、能使多名开发人员同时致力于同一个项目项或项目的一个分支,并维护所有项目项版本的逐条历史记录。
注 对于需要轻量级源代码管理解决方案的单个开发人员或小型团队,Microsoft 将继续增强并支持 Visual SourceSafe。我们将发布
Visual SourceSafe 2005,它的增强部分包括经由 HTTP 的远程 Web 访问、LAN 性能增强器、Unicode
和 XML 支持以及区域时区和语言支持等。有关详细信息,请参阅 Visual SourceSafe Roadmap。
Visual Studio Team Foundation 包括企业级源代码管理提供程序,它是 Visual SourceSafe
的继续。它可靠、可伸缩、快速、更安全、可扩展,并且几乎包含所有您和您的团队已经很熟悉且易于使用的 Visual SourceSafe
功能。
Visual Studio Team Foundation 源代码管理提供程序作为一个独立的 SCM 应用程序发布,或作为 Visual
Studio 2005 Team System 中的一个集成更改管理组件发布。在 Visual Studio 内部,通过使之成为项目文件管理的扩展,Team
Foundation 源代码管理插件可以降低源代码管理的复杂性。开发人员无需离开集成开发环境 (IDE) 或者打开另一个应用程序,即可执行所有源代码管理操作。
在 Visual Studio 内部或外部,Team Foundation 源代码管理提供程序与 Team System 组件(例如,工作项跟踪和报告)无缝集成。
源代码管理提供程序说明
Visual Studio Team Foundation 源代码管理提供程序被实现成为一项 ASP.NET Web 服务,它使您能够在
Internet 上的任何地方访问并管理源代码管理配置项。
源文件和项目元数据存储在 Microsoft SQL Server 数据库中。源代码管理操作以原子和事务的方式执行。这种体系结构有如下优点:
- 可伸缩性假如提供足够的硬件,您的版本控制数据库就可以包含超过千兆字节的数据。Team Foundation 支持 5 到
500 个用户。
- 完整性和可靠性:与基于文件的源代码管理应用程序相关的数据完整性问题的类型真正减少了。
- 速度:根据所需的操作,Team Foundation 比 Visual SourceSafe 快几个数量级。
团队内的开发:隔离和联合
任何软件配置管理 (SCM) 方法或应用程序的一个最主要的目标都是支持并行开发。
并行开发 就是同时编码、测试和构建多个软件应用程序组件版本的过程,可将人员从串行开发 的约束中解脱出来,在串行开发中,一个开发人员完成一项任务后下一个人才能开始另一项任务。并行开发允许多个人员以隔离
的方式工作,允许与其他开发人员同时安全地开发某一组件的相同或不同部分和版本。要发挥并行开发的优势,团队必须实现流程并使用工具,以便项目参与人员能够在小冲突变成大冲突之前,迅速、逐步及自动地(某些情况下)对其进行解决。
由于允许开发人员根据需要以隔离(仿佛开发一个单人项目)和联合的方式工作,Visual Studio Team Foundation
实现了并行开发,在进行 Get 和 Checkin 操作期间,顺利地将开发人员私人工作区中的待定更改与数据库版本合并起来。当发生修改冲突时,利用一种健壮的内置合并引擎,开发人员可以合并两个分支间的更改。您还可以选择插入第三方合并实用工具。
如果想临时预防对重要项目进行更改,您可以锁定数据库中的项。
企业源代码管理提供一种称为 Shelve 的存档命令,这使得创建和改用个人副本或项目分支以开发产品版本的修补程序或只是试用一种开发
changeset 临时副本的替代方法变得很轻松。
Visual Studio 中源代码管理的集成
在 Visual Studio 中,通过选择“New Project”对话框中的“Add to Source Control
Automatically”选项,您可以将所有的新解决方案和项目悄无声息地添加到 Visual Studio 2005 Team
System 的源代码管理存储库。在默认情况下,只要编辑源代码管理项,它们中所有的都会悄无声息地签出。
与过去的很多 Visual Studio 源代码管理插件不同,当重命名、移动或删除源代码管理项时,您不必担心您的组员不能正确地共享您的更改。在签入之前,该更改一直作为待定更改隔离在本地的工作区中。签入后,在其他用户下次执行
Get 或 Check In 操作时,该更改就被传播到他们的工作区。
其他的 Visual Studio Team Foundation 更改管理功能
扩展性问题
有关扩展性问题的全部信息,请参阅Visual Studio 2005 Team System:扩展套件。
托管 API 有时称为客户端 API,是客户和合作伙伴进行扩展的主要和首选接口。该 API 位于 Visual Studio
和 TFC 用户接口的客户端上。它是一种 .NET 托管接口,因此可以从任何 Visual Studio 语言进行访问。该 API
的概述在本文后面的“体系结构”部分有所涉及。集成和扩展性是工作项跟踪工具背后的主要原因。
认为该 API 仅位于客户端是不正确的。Visual Studio Integrated Platform (VSIP) 用户接口使用的相同
API 将在 Web 服务器上用于工作项跟踪 Web 应用程序。
小结
Visual Studio Team Foundation 提供集成的源代码管理、工作项跟踪、报告和自定义策略,这使得您的团队可以有效地管理软件开发项目中的更改。
|