通过

连续生成和部署

  • 项目

如果许多开发人员协作开发复杂软件项目，集成不同代码部分可能需要很长时间，并且该过程不可预知。 但是，如果持续生成和部署您的项目，您可以使此过程更加高效和可靠。

持续集成 (CI) 是尽可能频繁地将代码集成到共享储存库中的过程。 执行代码集成期间，如果生成中断或测试失败，系统将及时通知您代码中的错误。

Martin Fowler 对持续集成实践进行了分解，规定了以下步骤：

  • 保持单一源代码储存库。

  • 使生成自动化。

  • 使生成自我维持。

  • 每天至少签入一次。

  • 在 CI 服务器上生成每一次签入。

  • 保持快速生成。

  • 在克隆的生产环境中进行测试。

  • 使任何人都可以轻松获得最新的可执行文件。

  • 始终关注所发生的情况。

  • 使部署自动化。

有关更多信息，请参见 Martin Fowler 网站上的以下网页：Continuous Integration（持续集成）。

Visual Studio Application Lifecycle Management (ALM) 可帮助您管理软件开发的端对端过程，并支持持续集成实践。 通过利用 Visual Studio ALM 的功能，您的项目可以避免意外延迟、超支和执行风险。

主题内容

  • 管理依赖关系

  • Visual Studio 2010 中的持续集成

  • 准备与开始

  • 版本控制

  • 生成

  • 测试和部署

  • 项目集成和通信

管理依赖关系

由于代码之间的依赖关系，代码集成过程非常复杂。 例如，在屏幕上画圆的库依赖于系统数学库的 Sqrt() 方法。 如果 Sqrt() 方法发生更改，则必须相应更新该库。 硬件和操作系统的更改不会像团队项目那么频繁。 但是，如果忽略任何环境下的更改，则会导致灾难性的后果。 您可以尽早集成代码，查看它是否基于有效假设，并且是否按计划方式工作。

代码中的更改可能会以不同方式影响依赖关系。 下图显示了两种情况。 左侧示例中显示的更改相对来说比较独立， 而右侧示例中显示的更改则具有更大的潜在影响，因为它具有太多依赖关系。

生成和部署代码关系图

下图显示如果不持续集成代码并对代码进行更新，持续更改会产生怎样的综合影响。

连续生成和部署代码时间线

在步骤 1 中，代码块 h 发生了更改，这可能会对所有依赖代码块 a、b、d、e 和 f 造成影响。 在步骤 2 中，代码块 a 和 b 发生了更改。 如果团队没有集成步骤 1 和步骤 2，代码块 a 和 b 可能不再有效。 在步骤 3 中，代码块 f 发生了更改。 假设团队没有集成步骤 2 和步骤 3，此时代码块 b 已受到了影响、发生更改并再次受到影响。 因此，代码块 b 的修复可能有些难度。

Visual Studio 2010 中的持续集成

Visual Studio ALM 提供了集成工具集来支持持续集成。如下图所示，这些工具包括版本控制、生成、测试、针对实验室环境的部署、工作项跟踪和数据仓库功能。

连续生成和部署中的 TFS

首先，您可以使用 Team Foundation 版本控制管理分支、变更集以及彼此之间的集成。 每个团队成员都能使用工作区彼此独立地工作。 有关更多信息，请参见分支和合并和创建工作区以使用团队项目。

其次，您可以使用 Team Foundation Build 在自动和分布式系统中编译、测试和部署软件。 如上图所示，Team Foundation Build 具有两种类型的生成。 一种生成使用持续的生成类型来生成开发分支。另一种生成使用封闭签入生成类型来生成主分支。 Visual Studio Team Foundation Server 支持五种类型的生成：手动、持续（由每一次签入触发）、滚动（聚合签入，直到上一个生成完成）、封闭签入和计划。 有关更多信息，请参见创建基本生成定义、了解 Team Foundation Build 系统和签入由封闭签入生成控制的挂起的更改。

第三，使用 Visual Studio ALM 的实验室管理功能，可以帮助定义生成并将其部署到物理和虚拟实验室环境。 若要捕获在特定环境中运行时的集成错误，可将生成部署到实验室环境，然后在此生成上运行测试套件。 有关更多信息，请参见为应用程序生命周期使用虚拟实验室。

此外，Visual Studio ALM 中的测试功能在团队成员的计算机上、生成计算机上以及实验室环境内均可用。 首先，在开发人员的计算机上运行测试套件可捕获与最近更改或创建的代码相关的问题。第二，在生成计算机上运行测试可捕获与其他代码集成的相关问题。 第三，在实验室中运行测试可捕获与团队配置的特定环境相关的问题。 有关更多信息，请参见如何：在生成应用程序之后配置和运行计划的测试。

提示

运行测试时可以生成代码覆盖率指标，这些指标可用于了解测试用例可覆盖的代码广度。 不过，不能使用代码覆盖率衡量测试完整性或质量。 有关更多信息，请参见如何：使用自动测试的测试设置配置代码覆盖率。

第四，Visual Studio Team Foundation Server 是存储工作项的储存库。 可以创建、管理和跟踪指派给团队成员的工作项，例如，Bug 或任务。 如果在代码集成时中断生成，团队必须尽快修复问题。 您可以配置 Team Foundation Server 来为生成中断创建工作项。 有关更多信息，请参见跟踪 Bug、任务和其他工作项。

最后，Team Foundation Server 仓库和 SQL Server Analysis Services 仓库的数据库聚合并关联 Team Foundation Server 子系统提供的所有数据。 这些子系统包括版本控制、生成、测试、部署和工作项跟踪。 因此，您的团队可直观查看持续集成的端到端过程。有关更多信息，请参见 使用 Visual Studio ALM 的关系型数据仓库数据库生成报表。

准备与开始

您的团队可以按照以下进程开始使用持续集成和 Team Foundation Server：

  1. 使用 Team Foundation 版本控制将代码集成到单个代码库中。

  2. 在 Team Foundation Build 中创建手动生成类型。

  3. 运行自动测试用例来验证生成的质量。 如果没有适当的测试套件，请创建一个占位符测试套件，并导入一些自动测试用例。 该套件可用作今后测试的占位符。

  4. 确保将生成产生的结果二进制文件传递到共享位置。 此策略可帮助您诊断测试期间出现的问题。

  5. 使用 Microsoft 测试管理器捕获在特定环境中运行时的集成错误。

版本控制

版本控制系统为代码提供一个共享储存库。 小型团队可以使用单个分支。 但是，使用两个或多个分支更切合实际，因为您常常需要开发多个代码版本，并在不同里程碑发布您的项目。 有关如何创建和合并代码分支的更多信息，请参见 CodePlex 网站上的以下页面：Team Foundation Server Branching Guide 2.0（Team Foundation Server 分支指南 2.0）。

生成

在持续集成中，生成系统生成可以测试和部署的可执行组件。 此外，生成系统还会以编译错误和警告的形式提供反馈。 这些错误是由项目源中引入的更改导致的。

Team Foundation Build 提供以下生成类型：

  • 手动 – 由团队成员对生成进行排队。

  • 连续 – 每次签入到版本控制分支时对生成进行排队。

  • 滚动 – 累积生成，直到上一个生成完成。

  • 封闭签入 – 仅在成功合并和生成提交的更改时封闭签入才接受签入。

  • 计划 – 根据所定义的计划进行生成。

有关更多信息，请参见创建基本生成定义。

要成功实现持续集成，团队成员有哪些预期？

团队成员必须以最多耗时 10 分钟的生成方式组织其源。 对于大型项目，此频率可能无法实现。 通过使用 Team Foundation Server，您的团队可以配置各种生成不同的代码库子集的生成定义。 如果生成需要很长时间，可使用滚动生成类型来持续生成未更改代码的二进制文件。

如果发生生成中断，您的团队必须立即修复该生成。 假定主分支未受到不良反向集成的影响，则大多数生成中断是由于工作分支出现不良签入造成的，或者是由于从主线分支进行正向集成造成的。 最好在一段时间内将修复生成中断的任务指派给一名团队成员，然后在多名团队成员之间轮流指派此任务。

每天应该运行多少次生成？

当持续集成代码时，可以为每个分支上发生的每次签入运行一次持续生成。 也可以运行独立于签入的新代码的滚动生成。 有关更多信息，请参见创建基本生成定义和监视正在运行的生成的进度。

Team Foundation Server 如何才能帮助提高代码生成的速度？

配置生成定义以执行增量生成将有助于提高生成速度。 可使用生成日志确定生成速度缓慢的部分，您可以对这些部分进行改进。 有关更多信息，请参见将 Team Foundation Build 配置为增量生成。

Team Foundation Build 如何才能帮助缩放持续集成？

生成控制器和生成代理可帮助缩放持续集成周期。

有关更多信息，请参见了解 Team Foundation Build 系统。

测试和部署

测试和部署如何才能适应持续集成？

下图演示 Visual Studio ALM 中的测试和部署功能如何才能适应持续集成。

将测试融入连续集成中

首先，当持续集成代码时，您可以从生成本身查找代码问题。 在给定所使用的编译器的情况下，生成要么成功编译，要么编译失败。 您可以生成一份生成报表，该报表包含来自编译器的错误和警告消息。 在 Visual Studio ALM 中，生成报告还提供诸如在此生成中修复了哪些 Bug、此生成中包括哪些变更集以及生成期间是否运行了代码分析等信息。 通过使用 Visual Studio ALM，您可以验证代码的设计是否遵守团队定义的规则。 有关更多信息，请参见如何：对照层关系图验证 .NET 代码。

其次，您可以通过运行单元测试来查找代码问题。 这些测试对问题的诊断方式不同于编译器。 编译器规则会检查代码语法和语言构造的问题。 相比之下，单元测试（可在生成完成后对该生成运行）可验证代码功能的任何方面。 在给定一组单元测试的情况下，这些单元测试还可提供诸如生成的代码覆盖率之类的指标。 有关更多信息，请参见如何：使用自动测试的测试设置配置代码覆盖率。

通过使用 Microsoft 测试管理器，可以配置一个用于运行测试的特定环境。 独立的单元测试可提供功能性验证级别。 但是，环境必须具备以下两个重要方面：

  • 不断变化的环境可能影响代码的工作方式。 例如，在没有实验室管理环境的情况下，可能难以对网络设置和拓扑进行测试。

  • 在特定环境中自动执行代码部署可帮助您的团队缩短部署的时间，并可增加部署迭代的数量。

有关更多信息，请参见How to: Create an Environment from Virtual Machine Templates和设置测试计算机以运行测试或收集数据。

应该如何组织我的测试套件才能启用持续集成？

您可以运行对持续生成最重要的测试套件，因为测试太多会延迟生成的完成。 确保针对当前迭代运行这些测试。

在夜间或计划的生成周期中，您还可以运行以前生成中的测试以及在以前冲刺 (sprint) 中通过的功能验证完整测试。

持续集成会对测试团队产生怎样的影响？

持续集成可帮助确定包含错误的生成，以便测试团队不会浪费时间使用和安装不良生成。

项目集成和通信

根据项目的大小，实现持续集成的工作量可能非常庞大。 团队必须定义持续集成工作，并将此项工作安排到项目的第一个冲刺 (sprint) 中。

如果希望分阶段采用持续集成，您可以首先从实现自动生成开始。 接下来，您可以修改生成以包括运行单元测试。 最后，您可以添加将测试过的生成部署到实验室环境的功能，并且可在该环境中运行测试以验证不断变化的环境是否会对代码产生影响。