扩展 Team Foundation Server 从而实现连续集成

最新推荐文章于 2016-07-03 18:00:07 发布

yesbar

最新推荐文章于 2016-07-03 18:00:07 发布

阅读量1.7k

点赞数

文章标签： server 扩展单元测试测试工作敏捷开发

本文链接：https://blog.csdn.net/yesbar/article/details/675009

版权

本文讨论：

•	敏捷开发方法论
•	Visual Studio Team System 和Team Foundation Server
•	设置工作组项目
•	扩展 Team Foundation Server

本文使用以下技术：
Visual Studio 2005 Team System、Team Foundation Server

代码下载位置：
TeamSystem.exe (173KB)

本页内容

	敏捷方法
	连续集成
	Visual Studio 2005 Team System
	项目单元测试
	创建工作组项目
	创建生成单元测试
	定义生成过程
	扩展Team Foundation Server
	指定工作项
	小结

许多开发小组都采用"敏捷"方法管理变更，提高软件质量。随着新功能的添加、错误的修正和代码的重构，这些方法逐渐将连续集成提升为一种生成和测试软件产品的实践。那么，Visual Studio^® 2005 Team System 和 Team Foundation Server 是如何推动敏捷开发和连续集成的过程呢？

本文通过创建一个使用敏捷概念（如使用 Visual Studio 2005 Team System 中新单元测试功能的测试驱动开发 (TDD)）的示例项目对该问题做出回答。在项目完成后，我将说明如何使用 Team Foundation Server 创建工作组项目，以及使用该技术的扩展功能来生成自定义的 Web 服务，从而使连续集成在代码签入源代码管理之后生成应用程序。

敏捷方法

在深入特定的敏捷开发概念之前，回顾敏捷开发的历史以及详细说明促成特定的敏捷方法的要素很有用。

有几个方法作为处理密集开发模型（如 Rational Unified Process (RUP)）的备选方法,出现于 1990 年。某些开发人员认为，这些模型并没有表现出软件开发的动态特性（其中，优先级经常更改，而且用户反馈很重要）。通过实践，许多开发小组发现软件项目内置了许多形状和大小，并且重量级软件方法在许多情况下是不适合的，特别是规模更小、更动态的开发。例如，具有预测性质的瀑布式 (waterfall) 方法就无法针对快速变化的开发环境很好地进行伸缩。

极限编程 (extreme programming)、自适应软件开发 (adaptive software development) 和动态系统开发方法 (DSDM) 等方法的创建都是为了使项目管理人员和开发人员能够快速适应更改，同时又不牺牲质量。现在看来，这些方法明显具有许多公共主题，例如，快速响应客户反馈和业务需求的能力，了解客户对产品发展方向的要求，较短的开发周期，以及全面的测试覆盖。开发小组开始采用最适用于组织的方法，并不断地反馈效果以改进方法。

在 2001 年，一组精明的软件专家聚集在一起，讨论这些方法的共同点 - 涉及自适应软件开发的"五个系列"的会议。这些软件专家创造了术语"敏捷"来囊括这些方法的所有共同点。

从那时起，敏捷开发就成长起来，并且人们创建了许多协助它的工具。期间，开发小组不断从中获益。单元测试工具（如 NUnit）成为开发过程不可分割的一部分。同样，即使没有全部采用敏捷方法，连续集成也成为许多开发小组采用的标准做法。有关该主题的详细信息，请参阅"Resources for Agile Development"提要栏。

返回页首

连续集成

连续集成是一项简单、强大的技术，Martin Fowler 将其视为软件开发的最佳实践，同时它也是一项能够轻松适应敏捷开发过程的技术（请参阅 Continuous Integration）。连续集成通过在每次更改软件单元后生成软件产品，来进一步巩固"每日生成"的概念。在大多数情况下，每当开发人员将代码或配置更改签入源代码管理时，都会执行生成过程。生成过程会从中央源代码管理库获取所有文件，并编译生成脚本。生成过程的状态会连续地通知给开发人员和测试人员，以便快速捕获和修正失败的生成。这一过程的变化逐步递进，并在签入完成前执行生成，从而允许在签入导致中断时将其中止。

极限编程特别强调 TDD — 它天生就适合连续集成。TDD 建议开发人员编写测试用例（通常是单元测试），编写该测试使用的代码，运行自动测试，以及根据需要重构代码。有效地编写这些测试可获得能够对产品进行充分测试覆盖的单元测试。这些自动测试位于一个公共区域内，在将任何代码签入生成过程之前，所有开发人员和测试人员都可以运行它们。

这非常适合连续集成，因为在编译生成脚本之后，所有单元测试都会在最新的生成脚本上运行。如果有任何单元测试失败，则生成过程就会失败，因为某些代码无法正常运行。使测试用例覆盖尽可能多的产品以确保合格的产品，这一点非常重要。另一个较好的做法是，为修正后的错误生成单元测试，以便以连续的方式自动验证和检查错误。

连续集成的一个明显优势是透明度。失败的生成和测试可以很快被发现，而不是等待下一次生成。签入违规代码的开发人员可能还未走远，可以快速修正或回滚更改。如果测试用例编排得丰富且周全，则质量保证 (QA) 人员查找潜在错误的负担就很小，这可以让您放心地关注软件质量。结果，您可以用更多的时间来开发功能和进行重构，而花在尝试查找集成错误上的时间则很少。

尽管本文的其余部分主要讨论使用 Visual Studio 2005 Team System 和 Team Foundation Server 来实现单元测试和连续集成，但不使用这些工具也可从而实现连续集成。CruiseControl.NET 就是另一个为实现项目连续集成的工具示例。但是，我将为您说明 Team Foundation Server 如何自动化生成过程，以便与 Visual Studio 2005 中新的单元测试功能无缝集成在一起。

返回页首

Visual Studio 2005 Team System

有关 Visual Studio 2005 Team System 及其为开发小组提供的新功能的文章有很多。了解这些功能的一个好去处是 Chris Menegay 撰写的"Get All Your Devs in a Row with Visual Studio 2005 Team System"一文。

Team Foundation Server 是后端服务器组件，它驱动许多 Visual Studio Team System 功能。一个引人瞩目的功能是新的源代码管理系统。它能够替代 Visual SourceSafe^®，甚至具有出色的转换实用程序对现有源代码进行迁移。如果您选择不迁移，则可以使用已经发布的新版本 Visual SourceSafe。

除了源代码管理以外，Team Foundation Server 还提供了许多其他功能。您可以跟踪工作项（例如，错误、任务）和项目文档。这些项进行存储和版本化，并被视为与源代码一样有价值和必要。所有小组成员（而不仅仅是开发人员）每天完成任务所需的项存储在 Team Foundation Server 中，并通过 Visual Studio 用户界面显示，这可让您在最常用的工具中获得这些信息。

Team Foundation Server 由处理与 Visual Studio 客户端交互的 Web 服务驱动。SQL Server^® 2005 用于存储工作项，并将源代码作为不同版本间的压缩反增量来加以维护。SQL Server 的 Analysis Services 和 Reporting Services 可以提供与项目相关的测试结果、规格和代码活动的报告。Windows^® SharePoint^® Services 为项目协作和文档库提供了门户。项目组站点允许不使用 Visual Studio 的小组成员访问项目信息和资源。

源代码可以通过 Team Foundation Build Server（可以安装在单独的服务器上）集中编译。代码将从源代码管理系统中签出，然后生成并测试，所得到的生成输出可以通过网络共享访问。可以支持多个生成类型，从而使开发人员和配置管理器能够控制项目的生成方式。

由于大部分 Team Foundation Server 是使用 Microsoft^® .NET Framework 和 Web 服务编写的，因此可以通过订阅事件以及使用 Team Foundation 对象模型自动化任务来轻松地进行自定义。我将为您显示一个示例，该示例通过响应源代码管理签入事件来实现连续集成。

返回页首

项目单元测试

作为示例，我将根据极限编程原则来创建、测试和生成一个简单的 .NET 库。我将使用 .NET Framework 2.0 中的泛型来开发一个提供基本算术函数的数学组件。一般接口为算术函数（例如，add 和 substract）定义了方法。这将允许 Calculator 库根据类型调用正确的方法。示例库对于所述的概念并不重要，但我们可以对其进行研究以说明 .NET 泛型的用法。请注意，本文的所有代码都以 C# 和 Visual Basic^® 的形式提供。

正如所有专业的极限编程开发人员所作的那样，我将首先为希望实现的每个公共方法创建单元测试。通常，我在生成单元测试之前会"根除"公共属性和方法。Visual Studio 中新的类图表功能可以使该操作非常快速（参见图 1）。

图 1 CalculatorLibrary类图表

单元测试是为 CalculatorLibrary 类的公共方法创建的。使用 Visual Studio Team System，可以通过创建一个新的单元测试项目将单元测试添加到解决方案中，这允许您创建可以手动运行的 Web 页测试、负载测试、代码单元测试甚至文档测试。在本例中，代码单元测试类可以帮助测试数学方法的准确性。图 2 显示一个单元测试示例，该示例确保添加到列表中的所有项的总和为 86。如果遇到异常或值不是 86，则测试失败。

Initialize 方法定义了设置测试所需的所有工作。在本例中，创建了 Calculator 对象。测试初始化方法必须具有 TestInitialize 属性。同样，测试方法必须具有 TestMethod 属性。对于 Visual Studio 中的测试框架识别方法以及随后的生成产品，这些属性都很必要。

图 3 查看本地测试结果

一旦完成单元测试，就可以实现 Calculator 库了。然后，我就可以本地运行单元测试了。Test Manager 允许选择和执行当前解决方案中的所有测试。图 3 中的 Test Results 窗口显示，所有测试都已经通过，并且可以继续执行下一步；具体来说，就是在 Team Foundation Server 中创建一个新的工作组项目，并将解决方案添加到其中。

返回页首

创建工作组项目

在网络上设置 Team Foundation Server 以后，通过 Visual Studio 连接到服务器就很简单了。在 Tools 菜单中，只需选择 Connect to Team Foundation Server。还有一个选项可以将新服务器添加到在默认端口 8080 上运行的服务器（通常通过一个 URL）。在本例中，该 URL 是 TeamFoundation:8080。

当您连接到服务器时，可以创建一个新项目。通常，项目的名称比解决方案的名称更具体。我选择调用项目 MSDN Calculator，如图 4 所示。通常，工作组项目在编写代码之前创建，因为小组要经历所生成应用程序的定义阶段。工作组项目可能包含许多解决方案和 Visual Studio 项目，但更有趣的事情是，它所涉及的内容远远多于源代码管理。工作组项目包含具有特定角色的成员，他们遵循特定的软件开发方法，具有一组与方法相应的工作项类型，拥有一个与项目相关信息进行协作和通讯的门户，等等。这样，可能会获得一个更合适的工作组项目名称"Enterprise Infrastructure"，因为公司通常具有一组由许多应用程序共享的公共类，并需要工作组项目来管理他们的开发。但是，出于示例的简单性，我使用了 MSDN Calculator。

图 4 创建新的工作组项目

下几个步骤允许我更详细地定义项目。首先，我可以定义与所使用的开发方法相应的过程模板。对于 Beta 3，选择包括 Microsoft Solutions Framework (MSF) for Agile Software Development 和 MSF for CMMI Process Improvement。由于我使用的是极限编程方法，因此我选择敏捷开发模板。但是，请注意，这些模板可以自定义，并且您也可以创建新模板。这些模板很重要，因为它们可以定义工作项、报告和项目的安全设置。

下一步是设置项目的源代码管理。执行此操作的界面非常类似于 Visual SourceSafe，并且对于从该环境迁移的用户非常直观。对于该项目，我接受默认值，以创建一个在项目之后命名的空白源代码管理文件夹。

完成此步骤之后，会出现一个对话框来确认我进行的设置，然后创建一个新项目。这需要一段时间来完成，因为创建一个新项目需要许多工作。在后端，创建了 SharePoint 站点，生成了工作项，定义了报告，并根据过程模板配置了所有其他设置。此时，我可以为开发人员、测试人员和其他参与者定义角色，以便在项目上配置安全性。现在，我可以签入一些项，并定义生成设置。在本例中，我还可以扩展 Team Foundation Server 以支持连续集成。

至此，我已经创建了 .NET 库，完成了一组单元测试，并创建了一个新的工作组项目。下一步是准备单元测试，以便它们可以在 Team Foundation Build Server 上远程运行。

返回页首

创建生成单元测试

在 Visual Studio Team System 中，Test Manager 将自动创建一个具有 .vsmdi 扩展名的测试元数据文件。该文件包含项目的单元测试配置，这使得单元测试能够通过远程生成来运行。

在 Test Manager 中，我通过在左窗格中右键单击并选择 New Test List，创建了两个测试列表。我创建的一个列表用于放置将 Int 传递给 CalculatorLibrary 的单元测试，另一个用于包含传递 Double 的测试（参见图 5）。请注意，我没有包含任何手动测试，因为生成过程将在后台发生，无需人员交互。该数据将保存在 .vsmdi 文件中，而该文件将签入源代码管理。

图 5 Test Manager 中的项目测试配置

在 Team Foundation Server 中，有一个定义源代码管理签入策略的功能，但我没有选择为该项目配置该功能。签入策略是一个在一组开发人员之间实施一致性的出色功能。

图 6 项目内容

此时，解决方案和项目设置的配置如图 6 所示。这显示了包含 Calculator 库的主项目和单元测试项目。测试元数据文件也显示为绑定到源代码管理的解决方案项。

返回页首

定义生成过程

现在，我可以为该项目定义生成类型。在本例中，我将创建一个生成过程，以便将数学库和单元测试项目作为调试版本来编译，然后运行所定义的两个测试列表。我将该生成过程命名为连续集成。该名称将在我随后自定义生成过程时使用。如果该生成过程或者任何单元测试失败，我可以通过各种方法来通知开发人员修正问题。

在 Team Explorer 窗口中，Team Builds 选项允许您创建新的生成类型。该向导将引导您完成命名生成类型、选择要编译的项目以及指定生成计算机的过程。在我的配置中，我安装了生成服务并使其在 Team Foundation Server 上运行，但这可能不是典型方案，因为生成过程很可能在独立服务器上完成。向导的最后一页允许我选择在项目编译之后生成过程将运行的单元测试。本例，我选择了所定义的两组单元测试（参见图 7）。

图 7 选择在生成之后运行的测试

定义连续集成生成之后，测试它的最佳方法就是在 Visual Studio Team Explorer 用户界面范围内强制生成过程。连续集成生成可以在 Team Explorer 中的 Team Build 文件夹下看到。简单的右键单击将显示生成工作组项目的选项。生成状态在 Visual Studio 中报告。

返回页首

扩展Team Foundation Server

Team Foundation Server 的生成要考虑到扩展性。对于该功能，您可能最先注意到的是订阅事件（特别是源代码管理事件）的能力。名为 BisSubscribe.exe 的命令行实用工具包含在 Team Foundation Sever 安装中，并用于订阅这些类型的事件。但是，在设置订阅之前，会创建一个 Web 服务来捕获事件。在 Beta 3 中，BisSubscribe 实用工具位于 C:/Program Files/Microsoft Visual Studio 2005 Team Foundation Server/TF Setup 文件夹中。

BisSubscribe.exe 允许您定义要订阅的事件类型，它还可以定义确切的签名以及用于捕获事件的 Web 服务方法的属性。为 Notify Web 方法生成的代理如下所示，它们经过了修改以完成某些任务：

<SoapDocumentMethod(Action:="http://schemas.microsoft.com/
TeamFoundation/2005/06/Services/Notification/02/Notify", _     
RequestNamespace:="http://schemas.microsoft.com/TeamFoundation/2005/06/
Services/Notification/02"), WebMethod()> _
Public Sub Notify(ByVal eventXml As String)
    ' implement event functionality
    ThreadPool.QueueUserWorkItem(AddressOf BuildProject, eventXml)
End Sub

要创建订阅，您可以运行以下命令：

BisSubscribe /eventType CheckinEvent /userId PICCOLO/TFSSetup /address 
TeamFoundation:8080/Continuous/Build.asmx /deliveryType Soap /domain 
TeamFoundation

地址参数值得注意。这是包含 Notify Web 方法的 Web 服务的位置。最简单的位置是在 Web 站点下创建一个包含 Team Foundation Server Web 服务的附加虚拟根目录（这是因为 Team Foundation Server 应用程序池所运行的帐户具有读取源代码和启动生成过程的权限；如果您设置了其他 Web 服务，则需要确保它具有在生成期间用于执行所需操作的凭据）。这些 Web 服务的物理位置是 C:/Program Files/Microsoft Visual Studio 2005 Team Foundation Server/Web Services 文件夹。通过命令行选项可以看到，我添加了一个名为 Continuous 的虚拟根目录来处理这些请求。

Notify Web 方法在 eventXml 参数中接受 XML 文档。该文档包含特定事件的所有元数据。图 8 显示签入事件 XML，其中，我故意在 MathLibrary.cs 中签入了错误。

从 Notify Web 方法中，我调用了另一个可以生成项目并将结果报告给开发小组的方法。在图 9 中，我从事件 XML 中提取了所需的信息。创建生成过程需要两个步骤。首先，我需要创建传递给生成控制器以启动生成过程的参数。最少所需参数如示例所示。生成控制器需要 Team Foundation Server 名、项目名、生成服务器名，以及生成计算机上用于编译的目录。还必须指定预先定义的生成类型。在本例中，我提供了在前面的工作组项目中定义的连续集成生成类型。

定义生成参数之后，我可以获得一个 Build Controller 代理。这是一个 Web 服务代理，它使用已定义的参数调用 StartBuild 方法。StartBuild 方法会返回唯一的统一资源标识符 (URI)，以允许我检查生成状态。启动生成过程之后，会创建另一个代理以连接到 Build Store（在其中检查生成状态及其详细信息的对象）。为了确定生成过程是否完成，我使用了一个 while 循环来定期联络 Build Store，并从 StartBuild 方法传入 URI。

返回页首

指定工作项

完成后，我将检查生成状态。如果生成失败，我将调用 AssignWorkItem 方法为签入违规代码的开发人员指定一个事件。为此，我检索了另一个 Web 服务代理，这次是 Work Item Store。这允许我创建并保存一个新的工作项，如图 10 中的代码所示。

对于导致生成过程失败的开发人员，工作项将在 My Work Items 列表中显示为一个任务。基于故意签入的错误而指定的工作项如图 11 所示。该任务可以为开发人员提供修正错误所需的详细信息，还可以跟踪事件的完成时间。从这些工作项中可以派生出许多衡量标准，包括生成过程在迭代期间的中断次数，以及修正错误所花费的时间。所有这些信息都为开发工作提供了透明性。

图 11 自动指定的工作项

除了指定工作项，还可以将电子邮件发送到开发小组以警告生成状态。即使生成成功，也可以发送电子邮件。一个较好的扩展点是，集成发送即时消息的功能或者其他警告机制。针对失败生成的电子邮件示例如图 12 所示。

图 12 自动发送到开发小组的电子邮件

该电子邮件将提供指向新生成项目以及生成日志的链接。生成日志会包含所需的信息，以帮助确定生成或测试用例失败的原因。整个工作流是自动化的，无需任何人来检查状态或手动指定工作项，从而使开发小组能够将精力集中在最重要的项目上：生成高品质软件。

返回页首

小结

Visual Studio 2005 Team System 和 Team Foundation Server 具有许多支持敏捷开发方法论的功能。通过产品中内置的单元测试和工作项，在 Visual Studio 中使用 TDD 方法再简单不过了。正如所演示的那样，扩展 Team Foundation Server 以支持连续集成之类的做法就像捕获事件并连接到服务器基础结构一样简单。