持续集成 – 快速指南

---

持续集成 – 概述

持续集成于 2000 年首次通过名为Cruise Control的软件引入。多年来，持续集成已成为任何软件组织的关键实践。这是一种开发实践，它要求开发团队确保对软件程序的每个代码更改都进行构建和后续测试。这个概念旨在消除在构建生命周期中发现问题的后期出现的问题。引入了持续集成以确保代码更改和构建永远不会孤立地完成，而不是孤立地工作和集成不够的开发人员。

为什么要持续集成？

持续集成已成为任何软件开发过程中不可或缺的一部分。持续集成过程有助于为软件开发团队回答以下问题。

• 所有的软件组件是否按照它们应该的方式一起工作？– 有时系统会变得如此复杂，以至于每个组件都有多个接口。在这种情况下，确保所有软件组件彼此无缝工作始终至关重要。

• 代码对于集成来说是否过于复杂？– 如果持续集成过程不断失败，则代码可能过于复杂。这可能是应用适当设计模式以使代码更简单和更易于维护的信号。

• 代码是否符合既定的编码标准？– 大多数测试用例将始终检查代码是否符合正确的编码标准。通过在自动构建之后进行自动测试，这是检查代码是否满足所有所需编码标准的好方法。

• 自动化测试覆盖了多少代码？– 如果测试用例未涵盖代码所需的功能，则测试代码毫无意义。因此，确保编写的测试用例应涵盖应用程序的所有关键场景始终是一个好习惯。

• 最新更改后所有测试都成功了吗？– 如果测试失败，那么继续部署代码就没有意义了，因此这是检查代码是否准备好进入部署阶段的好时机。

工作流程

下图显示了整个持续集成工作流如何在任何软件开发项目中工作的快速工作流。我们将在后续章节中详细讨论这一点。

因此，基于上述工作流程，这通常是持续集成过程的工作方式。

• 首先，开发人员将代码提交到版本控制存储库。同时，集成构建机器上的持续集成服务器轮询源代码存储库的更改（例如，每隔几分钟）。

• 提交发生后不久，持续集成服务器检测到版本控制存储库中发生了更改，因此持续集成服务器从存储库中检索代码的最新副本，然后执行构建脚本，该脚本集成了软件

• 持续集成服务器通过将构建结果通过电子邮件发送给指定的项目成员来生成反馈。

• 如果该项目的构建通过，则执行单元测试。如果测试成功，代码就可以部署到临时服务器或生产服务器了。

• 持续集成服务器继续轮询版本控制存储库中的更改，并重复整个过程。

持续集成 – 软件

软件部分是任何持续集成过程中最重要的方面。本章重点介绍整个持续集成过程所需的软件。

源代码库

源代码存储库用于维护所有源代码和对其所做的所有更改。用于源代码存储库管理的两个最流行的系统是 subversion 和 Git，其中 Git 是最近流行的系统。我们现在将看看如何在系统上安装 Git。

系统要求

Memory	2 GB RAM（推荐）
Disk Space	200 MB HDD 用于安装。需要额外的存储空间来存储项目源代码，这取决于添加的源代码。
Operating System Version	可以安装在 Windows、Ubuntu/Debian、Red Hat/Fedora/CentOS、Mac OS X 上。

安装 Git

第 1 步– Git 的官方网站是https://git-scm.com/。如果您点击该链接，您将进入 Git 官网主页，如下图所示。

第 2 步– 要下载 Git，只需向下滚动屏幕并转到“下载”部分，然后单击“下载”。

第 3 步– 单击 Windows 链接，Git 下载将自动开始。

步骤 4 – 单击下载的 Git .exe 文件。在我们的例子中，我们使用的是 Git-2.6.1-64-bit.exe 文件。单击出现在下一个屏幕上的运行。

步骤 5 – 单击出现在以下屏幕上的下一步按钮。

步骤 6 – 在以下屏幕中单击下一步以接受通用许可协议。

步骤 7 – 选择 Git 安装的位置。

步骤 8 – 单击下一步接受需要安装的默认组件。

第 9 步– 选择“从 Windows 命令提示符使用 Git”选项，因为我们将在 Windows 中使用 Git。

第 10 步– 在以下屏幕中，接受“Checkout Windows 风格，提交 Unix 风格行尾”的默认设置，然后单击下一步。

步骤 11 – 在以下屏幕中，选择“使用 Windows 默认控制台窗口”选项，因为我们使用 Windows 作为安装 Git 的系统。

安装现在将开始，安装完成后可以按照后续步骤配置 Git。

配置 Git

安装 Git 后，需要执行配置步骤以对 Git 进行初始配置。

需要做的第一件事是在 Git 中配置身份，然后配置用户名和电子邮件。这很重要，因为每个Git 提交都会使用此信息，并且它会不可改变地融入您开始创建的提交中。可以通过打开命令提示符然后输入以下命令来做到这一点 –

git config –global user.name “Username”
git config –global user.email “emailid”

以下屏幕截图是一个示例，以便更好地理解。

这些命令实际上会相应地更改 Git 的配置文件。为确保您的设置已生效，您可以使用以下命令列出 Git 配置文件的设置。

git config --list

以下屏幕截图显示了输出示例。

持续集成服务器

整个持续集成管道所需的下一个关键软件是持续集成软件本身。以下是业内最常用的持续集成软件 –

• Jenkins – 这是一个开源持续集成软件，被许多开发社区使用。

• Jet Brains TeamCity – 这是最受欢迎的商业持续集成软件之一，大多数公司将其用于持续集成需求。

• Atlassian Bamboo – 这是另一种流行的持续集成软件，由一家名为 Atlassian Pvt 的公司提供。有限公司

上面提到的所有软件都使用相同的模型进行持续集成。出于本教程的目的，我们将着眼于持续集成服务器的Jetbrains TeamCity。

安装 TeamCity

以下是在您的计算机中安装 Jet Brains TeamCity 的步骤和系统要求。

系统要求

Memory	4 GB RAM（推荐）
Disk Space	1 GB 硬盘用于安装。需要额外的存储空间来存储每个项目的构建工作区。
Operating System Version	可以安装在 Windows、Linux、Mac OS X 上。

安装

第 1 步– TeamCity 的官方网站是https://www.jetbrains.com/teamcity/。如果单击给定的链接，您将转到 TeamCity 官方网站的主页，如下面的屏幕截图所示。您可以浏览该页面以下载 TeamCity 所需的软件。

步骤 2 – 下载的 .exe 用于执行TeamCity-9.1.6.exe。双击可执行文件，然后在弹出的下一个屏幕中单击运行。

步骤 3 – 单击下一步开始设置。

步骤 4 – 单击“我同意”按钮接受许可协议并继续安装。

步骤 5 – 选择安装位置，然后单击下一步。

步骤 6 – 选择安装的默认组件，然后单击下一步

这将开始安装过程。完成后，将遵循配置过程。

步骤 7 – 选择要运行的服务器的端口号。最好是使用不同的端口，例如8080。

第 8 步– 接下来它将询问 TeamCity 需要以哪个帐户运行。选择 SYSTEM 帐户，然后单击下一步。

步骤 9 – 接下来它将询问需要启动的服务。接受默认设置，然后单击下一步。

配置 TeamCity

安装完成后，下一步就是配置 TeamCity。该软件可以通过在浏览器中浏览以下 URL 来打开 –

http://locahost:8080

步骤 1 – 第一步是提供构建的位置，这将由 TeamCity 执行。选择所需的位置，然后单击继续按钮。

第 2 步– 下一步是指定用于存储所有 TeamCity 人工制品的数据库。出于本教程的目的，可以选择Internal (HSQLDB)，这是一种最适合将产品用于测试目的的内部数据库。

然后，TeamCity 将处理所有必要的步骤以使其启动和运行。

步骤 3 – 接下来，您将被要求接受许可协议。接受相同的内容并单击继续。

步骤 4 – 您需要创建一个管理员帐户，用于登录 TeamCity 软件。输入所需的详细信息，然后单击“创建帐户”按钮。

您现在将登录到 TeamCity。

构建工具

构建工具是一种确保程序以特定方式构建的工具。该工具通常会执行一系列任务，这些任务是以正确方式构建程序所必需的。由于在我们的示例中，我们将查看.Net 程序，因此我们将查看MSBuild作为构建工具。MSBuild 工具查看包含用于构建项目的任务列表的构建文件。让我们看一个典型的 Web 配置项目的 Build 文件。

以下是构建文件的关键部分，需要考虑。

IIS 设置

以下设置用于确定端口号、Web 服务器上的路径以及应用程序运行时需要的身份验证类型。这些是重要的设置，当我们在本教程后面了解如何执行部署时，将通过 MSBuild 命令更改这些设置。

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPor>
<DevelopmentServerPort>61581</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://localhost:61581/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>

项目组

这用于告诉构建服务器运行此项目所需的所有相关二进制文件是什么。

<ItemGroup>
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />

<ItemGroup>
   <Compile Include = "App_Start\BundleConfig.cs" />
   <Compile Include = "App_Start\FilterConfig.cs" />

.Net 框架版本

该TargetFrameworkVersion告诉这是净的版本需要存在，为项目工作。这是绝对需要的，因为如果构建服务器没有这个，构建将失败。

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

部署环境——亚马逊

出于本教程的目的，我们将确保我们的持续集成服务器能够将我们的应用程序部署到 Amazon。为此，我们需要确保以下人工制品到位。

数据库服务器

执行以下步骤以确保数据库服务器在 Amazon 中就位以进行部署。

第 1 步– 转到亚马逊控制台 – https://aws.amazon.com/console/。

使用您的凭据登录。请注意，您可以在亚马逊网站上申请一个免费 id，这将使您拥有一个免费套餐，允许您免费使用亚马逊上的一些资源。

步骤 2 – 转到 RDS 部分以创建您的数据库。

步骤 3 – 在弹出的下一个屏幕中单击实例。

Step 4 –在出现的下一个屏幕中单击Launch DB选项。

步骤 5 – 选择 SQL Server 选项卡，然后选择 SQL Server Express 的选择选项。

步骤 6 – 确保输入以下详细信息以确认您使用的是 Amazon 提供的免费数据库层。

步骤 7 – 填写所有字段后，单击下一步按钮。

步骤 8 – 在出现的下一个屏幕中，接受所有默认设置并单击Launch DB Instance。

第 9 步– 然后您将看到一个屏幕，表明数据库正在成功启动。在同一页面上，会有一个按钮来查看数据库实例。单击链接以查看正在设置的数据库实例。

一段时间后，上述屏幕的状态将发生变化，通知已成功创建数据库实例。

网络服务器

下一步是在 Amazon 上创建您的 Web 服务器，它将托管 Web 应用程序。这可以通过执行后续步骤来实现。

第 1 步– 转到亚马逊控制台 – https://aws.amazon.com/console/。

使用您的凭据登录。请注意，您可以在亚马逊网站上申请一个免费 id，这将使您拥有一个免费套餐，允许您免费使用亚马逊上的一些资源。

第 2 步– 转到EC2 部分以创建您的 Web 服务器。

步骤 3 – 在下一个屏幕中，单击启动实例。

步骤 4 – 单击 Windows – Microsoft Windows Server 2010 R2 Base。

步骤 5 – 选择t2.micro选项，这是免费套餐的一部分。单击下一步：配置实例详细信息。

步骤 6 – 在出现的下一个屏幕上接受默认设置，然后选择选项Next: Add Storage。

步骤 7 – 接受下一个屏幕上的默认设置并选择选项Next: Tag Instance。

步骤 8 – 接受下一个屏幕上的默认设置并选择Next: Configure Security Group选项。

步骤 9 – 接受下一个屏幕上的默认设置并选择Review and Launch选项。

步骤 10 – 在出现的下一个屏幕中单击启动。

步骤 11 – 在出现的下一个屏幕中，系统将提示您创建密钥对。这将用于稍后登录服务器。只需创建密钥对并单击Launch Instance 即可。

现在将在 Amazon 中设置该实例。

持续集成 – 降低风险

项目有可能出现问题。通过有效地实践 CI，您会发现在整个过程中的每一步都发生了什么，而不是在项目进入开发周期之后。CI 可帮助您在风险发生时识别和减轻风险，从而更轻松地根据具体证据评估和报告项目的健康状况。

本节将重点介绍使用持续集成可以避免的风险。

在任何项目中，都有许多需要管理的风险。通过在开发生命周期的早期消除风险，这些风险在系统实际上线时发展为问题的可能性较小。

风险 1 – 缺乏可部署的软件

“它可以在我的机器上运行，但不能在另一台机器上运行” ——这可能是任何软件组织中最常见的短语之一。由于每天对软件构建所做的更改数量很多，有时对软件构建是否真正有效几乎没有信心。这种担忧具有以下三个副作用。

• 对我们是否可以构建软件几乎没有信心。

• 在内部（即测试团队）或外部（即客户）交付软件之前的漫长集成阶段，在此期间没有其他任何事情完成。

• 无法生成和复制可测试的构建。

解决方案

消除 IDE 和构建过程之间的紧密耦合。使用单独的机器来单独集成软件。确保构建软件所需的一切都包含在版本控制存储库中。最后，创建一个持续集成系统。

持续集成服务器可以监视版本控制存储库中的更改，并在检测到存储库发生更改时运行项目构建脚本。可以增加持续集成系统的功能，包括通过测试运行构建、执行检查以及在开发和测试环境中部署软件；通过这种方式，您始终拥有一个可以运行的软件。

“无法与数据库同步” ——有时开发人员在开发过程中无法快速重新创建数据库，因此很难进行更改。通常这是由于数据库团队和开发团队之间的分离。每个团队都将专注于自己的职责，彼此之间几乎没有合作。这种担忧有以下三个副作用 –

• 害怕更改或重构数据库或源代码。

• 难以用不同的测试数据集填充数据库。

• 难以维护开发和测试环境（例如，开发、集成、QA 和测试）。

解决方案

上述问题的解决方案是确保在版本控制存储库中放置所有数据库工件。这意味着需要重新创建数据库模式和数据所需的一切：数据库创建脚本、数据操作脚本、存储过程、触发器和任何其他数据库资产。

通过删除和重新创建数据库和表，从构建脚本重建数据库和数据。接下来，应用存储过程和触发器，最后插入测试数据。

测试（并检查）您的数据库。通常，您将使用组件测试来测试数据库和数据。在某些情况下，您需要编写特定于数据库的测试。

风险 2 – 在生命周期后期发现缺陷

由于多个开发人员经常对源代码进行如此多的更改，因此总是有可能在代码中引入只能在后期检测到的缺陷。在这种情况下，这会造成很大的影响，因为在软件中检测到缺陷的时间越晚，消除缺陷的成本就越高。

解决方案

回归测试– 这是任何软件开发周期、测试和再次测试中最重要的方面。如果软件代码有任何重大变化，确保所有测试都运行是绝对强制性的。这可以在持续集成服务器的帮助下自动化。

测试覆盖率– 如果测试用例没有覆盖代码的全部功能，则测试没有意义。确保为测试应用程序而创建的测试用例是完整的并且所有代码路径都经过测试非常重要。

例如，如果您有一个需要测试的登录屏幕，您就不能拥有一个包含成功登录场景的测试用例。您需要有一个否定测试用例，其中用户输入不同的用户名和密码组合，然后需要查看在这种情况下会发生什么。

风险 3 – 缺乏项目可见性

手动沟通机制需要大量协调，以确保将项目信息及时传播给合适的人。向旁边的开发人员求助，让他们知道最新版本在共享驱动器上是相当有效的，但它的扩展性不是很好。

如果有其他开发人员需要此信息，但他们正在休息或以其他方式不可用怎么办？如果服务器出现故障，您如何收到通知？有些人认为他们可以通过手动发送电子邮件来降低这种风险。但是，这无法确保在正确的时间将信息传达给正确的人，因为您可能会不小心遗漏了感兴趣的各方，并且有些人当时可能无法访问他们的电子邮件。

解决方案

这个问题的解决方案再次是持续集成服务器。所有 CI 服务器都可以在构建失败时自动触发电子邮件。通过向所有关键利益相关者自动通知，还可以确保每个人都了解软件的当前状态。

风险 4 – 低质量软件

有缺陷，然后有潜在的缺陷。如果您的软件设计不当，或者不符合项目标准，或者维护起来很复杂，则可能存在潜在缺陷。有时人们将其称为代码或设计气味——“一种可能出现问题的症状。”

有些人认为，低质量的软件只是延迟的项目成本（交付后）。这可能是一个延期的项目成本，但在您将软件交付给用户之前，它也会导致许多其他问题。过于复杂的代码、不遵循架构的代码以及重复的代码——所有这些通常都会导致软件出现缺陷。在这些代码和设计异味显现为缺陷之前发现它们可以节省时间和金钱，并且可以产生更高质量的软件。

解决方案

有一些软件组件可以与 CI 软件集成来执行代码质量检查。这可以在代码构建后运行，以确保代码实际上符合正确的编码指南。

持续集成 – 版本控制

版本控制系统，也称为源代码控制、源代码管理系统或修订控制系统，是一种用于保存文件多个版本的机制，以便在修改文件时仍然可以访问以前的修订版本。

第一个流行的版本控制系统是一个专有的 UNIX 工具，称为SCCS（源代码控制系统），其历史可以追溯到 1970 年代。这被RCS（修订控制系统）和后来的CVS（并发版本系统）取代。

现在最流行的版本控制系统是Subversion和Git。让我们先看看为什么我们需要使用版本控制系统，接下来让我们看看将我们的源代码放在Git 源代码存储系统中。

版本控制系统的目的

我们优先使用术语版本控制而不是源代码控制的原因之一是版本控制不仅仅针对源代码。与软件创建相关的每个工件都应处于版本控制之下。

开发人员应将其用于源代码– 默认情况下，所有源代码都需要存储在版本控制系统中

相关人工制品– 每个系统都有与源代码相关的人工制品，例如数据库脚本、构建和部署脚本、文档、应用程序的库和配置文件、编译器和工具集合等。所有这些都是对整个开发和部署过程的补充，也需要存储在版本控制系统中。

通过将应用程序的所有信息存储在源代码管理中，重新创建应用程序运行的测试和生产环境变得更加容易。这应该包括应用程序软件堆栈和构成环境的操作系统的配置信息、DNS 区域文件、防火墙配置等。

至少，您需要重新创建应用程序的二进制文件及其运行环境所需的一切。目标是以受控方式存储在项目生命周期中任何时候可能发生变化的所有内容。这允许您在项目历史的任何时间点恢复整个系统状态的准确快照，从开发环境到生产环境。

将开发团队的开发环境的配置文件保留在版本控制中甚至很有帮助，因为它使团队中的每个人都可以轻松使用相同的设置。分析师应该存储需求文档。测试人员应该将他们的测试脚本和过程保持在版本控制中。项目经理应该在此处保存他们的发布计划、进度图表和风险日志。

简而言之，团队的每个成员都应该将与项目相关的任何文档或文件存储在版本控制中。

使用 Git 实现源代码版本控制系统

本节现在将重点介绍如何将 Git 用作版本控制系统。它将重点介绍如何将代码上传到版本控制系统并管理其中的更改。

我们的演示应用程序

为了整个教程的目的，我们将研究一个简单的Web ASP.Net应用程序，它将用于整个持续集成过程。在本练习中，我们不需要关注整个代码细节，只需大致了解项目的作用就足以理解整个持续集成过程。这个 .Net 应用程序是使用Visual Studio 集成开发环境构建的。

下面的截图是 Visual Studio 环境中解决方案的结构。这是一个非常简单的 Web 应用程序，其主要代码位于Demo.aspx文件中。

Demo.aspx 文件中的代码显示在以下程序中 –

<html xmlns = "http://www.w3.org/1999/xhtml">
   <head runat = "server">
      <title>TutorialsPoint</title>
   </head>
   
   <body>
      <form id = "form1" runat="server">
         <div><%Response.Write("Continuous Integration"); %></div>
      </form>
   </body>
   
</html>

代码非常简单，只是向浏览器输出字符串“Continuous Integration”。

当您在 Google Chrome 中运行该项目时，输出将如下面的屏幕截图所示。

将源代码移至 Git

我们将展示如何从命令行界面将源代码移动到 Git，以便最终用户更清楚地了解如何使用 Git。

步骤 1 – 初始化Git 存储库。转到命令提示符，转到您的项目文件夹并发出命令git init。该命令会将必要的 Git 文件添加到项目文件夹中，以便在需要上传到存储库时能够被 Git 识别。

第 2 步– 添加需要添加到 Git 存储库的文件。这可以通过发出git add 命令来完成。点选项告诉 Git 需要将项目文件夹中的所有文件添加到 Git 存储库中。

Step 3 – 最后一步是将项目文件提交到 Git 存储库。这一步是确保所有文件现在都是 Git 的一部分所必需的。要发出的命令在以下屏幕截图中给出。该-m选项是提供文件的上传评论。

您的解决方案现已在 Git 中可用。

持续集成 – 特性

以下是持续集成的一些主要功能或实践。

• 维护单一源存储库– 所有源代码都维护在一个存储库中。这避免了源代码分散在多个位置。工具如Subversion和Git的是保持源代码的最流行的工具。

• 自动化构建– 软件的构建应该以可以自动化的方式进行。如果需要执行多个步骤，则构建工具需要能够执行此操作。对于 .Net，MSBuild 是默认构建工具，对于基于 Java 的应用程序，您可以使用Maven 和 Grunt等工具。

• 让您的构建自我测试– 构建应该是可测试的。构建发生后，应立即运行测试用例，以确保可以对软件的各种功能进行测试。

• 每个提交都应该在集成机器上构建– 集成机器是构建服务器，应该确保构建在这台机器上运行。这意味着所有依赖组件都应该存在于持续集成服务器上。

• 保持快速构建– 构建应该在几分钟内发生。构建不应花费数小时，因为这意味着构建步骤未正确配置。

• 在生产环境的克隆中进行测试– 构建环境本质上应该与生产环境接近。如果这些环境之间存在巨大差异，那么即使在构建服务器上通过，构建也可能在生产中失败。

• 每个人都可以看到发生了什么– 构建、测试和部署的整个过程应该对所有人可见。

• 自动化部署– 持续集成导致持续部署。确保构建应该易于部署到临时或生产环境中是绝对必要的。

持续集成 – 需求

以下是持续集成最重要的需求列表。

• 定期签入 – 持续集成正常工作的最重要做法是频繁签入源代码存储库的主干或主线。代码的签入应该每天至少发生几次。定期办理登机手续会带来许多其他好处。它使更改更小，因此不太可能破坏构建。这意味着当任何后续构建中出现错误时，可以知道要恢复到的最新软件版本。

  它还有助于在重构代码方面更加自律，并坚持保留行为的小改动。它有助于确保更改大量文件的更改不太可能与其他人的工作发生冲突。它允许开发人员更具探索性，尝试想法并通过恢复到最后提交的版本来丢弃它们。

• 创建一个全面的自动化测试套件– 如果您没有一个全面的自动化测试套件，则通过的构建仅意味着可以编译和组装应用程序。虽然对于某些团队来说这是一个很大的进步，但必须进行一定程度的自动化测试以确保您的应用程序实际运行。

  通常，在持续集成中进行 3 种类型的测试，即单元测试、组件测试和验收测试。

  编写单元测试是为了单独测试应用程序的一小部分的行为。它们通常可以在不启动整个应用程序的情况下运行。它们不会访问数据库（如果您的应用程序有）、文件系统或网络。它们不需要您的应用程序在类似生产的环境中运行。单元测试应该运行得非常快——你的整个套件，即使是一个大型应用程序，也应该能够在 10 分钟内运行。

  组件测试测试应用程序的多个组件的行为。与单元测试一样，它们并不总是需要启动整个应用程序。但是，它们可能会访问数据库、文件系统或其他系统（这些系统可能会被删除）。组件测试通常需要更长的时间才能运行。

• 保持构建和测试过程简短– 如果构建代码和运行单元测试花费的时间太长，您将遇到以下问题。

  • 人们将停止进行完整的构建，并将在签入之前运行测试。您将开始获得更多失败的构建。

  • 持续集成过程将花费很长时间，以至于在您可以再次运行构建时已经发生了多次提交，因此您不知道哪个签入破坏了构建。

  • 人们将减少签入的频率，因为他们必须长时间等待软件构建和测试运行。

• 不要签入损坏的构建– 持续集成的最大错误是签入损坏的构建。如果构建中断，负责的开发人员正在等待修复它。他们会尽快确定损坏的原因并修复它。如果我们采用这种策略，我们将始终处于最佳位置，可以找出导致损坏的原因并立即修复。

  如果我们的一位同事进行了签入并因此破坏了构建，那么为了有最好的机会修复它，他们需要明确地解决问题。当这条规则被打破时，修复构建不可避免地需要更长的时间。人们习惯于看到构建已损坏，很快您就会陷入构建始终处于损坏状态的情况。

• 提交前始终在本地运行所有提交测试– 始终确保为应用程序设计的测试首先在本地机器上运行，然后再在 CI 服务器上运行。这是为了确保编写正确的测试用例，如果 CI 过程中有任何失败，那是因为测试结果失败。

• 对因更改而导致的所有损坏负责– 如果您提交了更改并且您编写的所有测试都通过了，但其他测试失败了，则构建仍然被破坏。通常这意味着您在应用程序中引入了回归错误。您有责任（因为您进行了更改）修复所有因更改而未通过的测试。在 CI 的上下文中，这似乎是显而易见的，但实际上这在许多项目中并不常见。

持续集成 – 构建解决方案

有多种构建工具可用于各种编程语言。一些最流行的构建工具包括用于 Java 的 Ant和用于 .NET 的 MSBuild。使用专为构建软件而设计的脚本工具，而不是一组自定义的 shell 或批处理脚本，是开发一致、可重复的构建解决方案的最有效方式。

那么为什么我们需要一个构建过程来开始。对于初学者来说，对于持续集成服务器来说，构建过程应该易于使用并且应该无缝实现。

让我们举一个简单的例子来说明 .Net 的构建文件是什么样的 –

<?xml version = "1.0" encoding = "utf-8"?>
<project xmlns = "http://schemas.microsoft.com/developer/msbuild/2003">
   <Target Name = "Build">
      <Message Text = "Building Project" />
      <MSBuild Projects = "project.csproj" Targets = "Build/>"
   </Target>
</project>

关于上述代码需要注意以下几个方面 –

• 目标以构建名称指定。其中，目标是构建过程中需要执行的逻辑步骤的集合。您可以有多个目标，并且目标之间存在依赖关系。

• 在我们的目标中，我们保留了一个选项消息，它将在构建过程开始时显示。

• 该MSBuild任务是用于指定.NET项目需要待建。

上面的例子是一个非常简单的构建文件的例子。在持续集成中，确保此文件保持最新，以确保整个构建过程是无缝的。

在 .Net 中构建解决方案

.Net 的默认构建工具是 MSBuild，它是 .Net 框架附带的。根据您系统上的框架，您将拥有可用的相关 MSbuild 版本。例如，如果您在默认位置安装了 .Net 框架，您将在以下位置找到MSBuild.exe文件 –

C:\Windows\Microsoft.NET\Framework\v4.0.30319

让我们看看如何构建我们的示例项目。假设我们的示例项目位于名为C:\Demo\Simple的文件夹中。

为了使用 MSBuild 构建上述解决方案，我们需要打开命令提示符并使用 MSBuild 选项，如以下程序所示。

msbuild C:\Demo\Simple\Simple.csproj

在上面的示例中，csproj是特定于 .Net 的项目文件。csproj 文件包含所有相关信息，以确保提供正确构建软件所需的信息。以下是 MSBuild 命令输出的屏幕截图。

只要构建成功并且没有错误，您就无需担心输出警告。

持续集成 – 构建脚本

现在让我们看看 MSBuild 文件的某些方面，看看它们的含义。从持续集成周期中了解这些方面很重要。

构建脚本用于构建解决方案，该解决方案将成为整个持续集成周期的一部分。让我们看看作为示例解决方案在.Net 中作为Visual Studio 的一部分创建的通用构建脚本。构建脚本是一个相当大的脚本，即使是一个简单的解决方案，所以我们将介绍其中最重要的部分。默认情况下，构建脚本将存储在与 Visual Studio 中的主解决方案同名的文件中。因此，在我们的示例中，如果您打开文件Simple.csproj，您将看到将用于构建解决方案的所有设置。

• 依赖于使用的 MSBuild 版本 – 以下设置将使用安装在 CI 服务器上的 MSBuild 文件。

<VisualStudioVersion Condition = "'$(VisualStudioVersion)' == 
   ''">10.0</VisualStudioVersion>

<VSToolsPath Condition = "'$(VSToolsPath)' == ''"> 
   $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)
</VSToolsPath>

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

<Import Project = "$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project = "$(VSToolsPath)\WebApplications\
   Microsoft.WebApplication.targets" Condition = "'$(VSToolsPath)' ! = ''" />

<Import Project = "$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\
   WebApplications\Microsoft.WebApplication.targets" Condition = "false" />

• 正确构建解决方案所需的文件 – ItemGroup标记将包含成功构建项目所需的所有必要 .Net 文件。这些文件需要相应地驻留在构建服务器上。

<ItemGroup>
   <Reference Include = "Microsoft.CSharp" />
   <Reference Include = "System.Web.DynamicData" />
   <Reference Include = "System.Web.Entity" />
   <Reference Include = "System.Web.ApplicationServices" />
   <Reference Include = "System.ComponentModel.DataAnnotations" />
   <Reference Include = "System" />
   <Reference Include = "System.Data" />
   <Reference Include = "System.Core" />
   <Reference Include = "System.Data.DataSetExtensions" />
   <Reference Include = "System.Web.Extensions" />
   <Reference Include = "System.Xml.Linq" />
   <Reference Include = "System.Drawing" />
   <Reference Include = "System.Web" />
   <Reference Include = "System.Xml" />
   <Reference Include = "System.Configuration" />
   <Reference Include = "System.Web.Services" />
   <Reference Include = "System.EnterpriseServices"/>
</ItemGroup>

• 要使用的 Web 服务器设置是什么 – 当我们访问我们的持续部署主题时，您将看到 MSBuild 将如何用于覆盖这些设置并将其部署到我们选择的服务器。

<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>59495</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl></IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>

CI – 在服务器上构建

下一个重要步骤是确保解决方案构建在构建服务器上。第一部分是手动步骤，因为在使用持续集成工具之前，我们首先必须确保构建在构建服务器上以与在客户端机器上所做的相同的方式运行。为此，我们必须执行以下步骤 –

步骤 1 – 将整个解决方案文件复制到服务器。我们创建了一个 Amazon 实例服务器，它将用作我们的构建服务器。因此，将整个.Net解决方案的服务器手动复制到服务器上。

步骤 2 – 确保框架存在于服务器上。如果您在客户端机器上用 .Net framework 4.0 编译了应用程序，则必须确保它也安装在服务器机器上。因此，转到服务器上的位置C:\Windows\Microsoft.NET\Framework并确保存在所需的框架。

第 3 步– 现在让我们在服务器上运行 MSBuild，看看会发生什么。

好的，看起来我们遇到了错误。持续集成中有一个重要的教训，那就是您需要确保构建在构建服务器上工作。为此，您需要确保在构建服务器上安装了所有必备软件。

对于 .Net，我们需要安装一个名为Visual Studio Redistributable package 的组件。该软件包包含在服务器上构建.Net应用程序所需的所有必要文件。那么让我们在构建服务器上执行以下安装步骤。

步骤 4 – 双击可执行文件开始安装。

步骤 5 – 在下一步中，同意许可条款并单击安装。

第 6 步– 现在运行 MSBuild 时，我们需要确保在调用 MSBuild 时包含一个附加参数，即 – p:VisualStudioversion = 12.0。这可确保 MSBuild 引用在先前步骤中下载的那些文件。

现在我们可以看到解决方案已经正确构建，我们也知道我们的基线项目在服务器上正确构建。

CI – 检查源代码

下一个关键方面是确保我们的基线代码被检入我们的源代码存储库管理服务器，即 Git。为此，我们需要按照以下步骤操作。

步骤 1 – 初始化存储库，以便可以将其上传到 Git。这是通过git init 命令完成的。所以你需要转到你的项目文件夹并发出git init命令。

步骤 2 – 下一步称为 Git 中的暂存文件。这准备了项目文件夹中的所有文件，这些文件需要添加到 Git。您可以使用git add命令执行此操作，如下面的屏幕截图所示。这 ‘。’ 符号用于表示目录和子目录中的所有文件都应包含在提交中。

Step 3 – 最后一步是将文件提交到 Git 存储库，以便它现在是一个成熟的 Git 存储库。

CI – 在 TeamCity 中创建项目

现在我们在 Git 存储库中有我们的源代码并且我们所有的初始代码都在构建服务器上运行，是时候在我们的持续集成服务器中创建一个项目了。这可以通过以下步骤完成 –

步骤 1 – 登录 TeamCity 软件。转到持续集成服务器上的 url – http://localhost:8080/login.html。

输入管理员凭据并登录到服务器。

步骤 2 – 登录后，您将看到主屏幕。单击创建项目以启动新项目。

步骤 3 – 为项目命名，然后单击创建以启动项目。在我们的例子中，我们给我们的项目命名为“Demo”，如下面的屏幕截图所示。

第 4 步– 下一步是提及将在我们的项目中使用的 Git 存储库。请记住，在持续集成环境中，CI 服务器需要从启用 Git 的存储库中获取代码。我们已经在前面的步骤中使我们的项目文件夹成为启用 Git 的存储库。在 TeamCity 中，您需要创建一个 VCS 根。为此，请单击项目主屏幕中的VCS Roots。

步骤 5 – 在接下来出现的屏幕中，单击创建 VCS 根，如下面的屏幕截图所示。

步骤 6 – 在出现的下一个屏幕中，执行以下步骤 –

• 将 VCS 的类型称为 Git。

• 为 VCS 根命名，可以是任何友好名称。我们将名称命名为App。

• 将 Fetch url 指定为C:\Demo\Simple – 这是启用git 的存储库。

• 如果向下滚动屏幕，您将看到一个测试连接按钮。单击它以确保您可以成功连接到启用 Git 的存储库。

步骤 7 – 单击创建，您现在将看到您的存储库已注册，如下图所示。

步骤 8 – 下一步是创建将用于构建项目的构建配置。转到TeamCity → 常规设置中的项目屏幕。单击创建构建配置。

步骤 9 – 在以下屏幕中，为构建配置命名。在我们的例子中，我们将其命名为DemoBuild，然后单击 Create。

步骤 10 – 在出现的下一个屏幕中，您将被要求选择在前面的步骤中创建的VCS 存储库。因此，选择名称“App”并单击“附加”。

步骤 11 – 现在在弹出的下一个屏幕中，我们需要配置构建步骤。因此，单击“手动配置构建步骤”超链接。

步骤 12 – 在下一个构建屏幕中，我们需要输入以下详细信息 –

• 选择 Runner 类型作为 MSBuild。

• 为步骤名称提供可选名称。

• 给出需要构建的文件的名称。当我们在前面的部分中指定 MSbuild 时，我们通常会看到我们给出了Simple.csproj选项。同样的事情需要在这里指定。

• 选择 MSBuild 版本为“Microsoft Build Tools 2013”​​。

• 选择MSBuild ToolsVersion作为 12.0。

• 向下滚动页面以保存设置。

步骤 13 – 在下一个屏幕中，单击运行。

您将看到您的应用程序的构建正在进行中。

您应该获得一个成功的屏幕，这是您的解决方案构建正确的好兆头。

您还可以转到构建日志以查看持续集成服务器涵盖的所有步骤，如下面的屏幕截图所示。

持续集成 – 定义任务

现在我们在 Git 中有了我们的基本代码和一个到持续集成服务器的链接，现在终于可以看到持续集成的第一步了。这是通过在持续集成服务器中定义任务（例如触发器）来完成的，这使得整个持续集成过程尽可能无缝。让我们对 Visual Studio 中的代码进行更改。

步骤 1 – 转到Visual Studio 中的Demo.aspx页面并更改页面标题。

第 2 步– 如果我们通过git status命令查询我们的 Git 存储库，您实际上会看到Demo.aspx文件已被修改。

现在我们需要确保我们代码中的每一个更改都应该触发我们的持续集成服务器中的构建。为此，我们需要进行以下更改。

步骤 3 – 转到您的项目仪表板并单击触发器部分，然后单击添加新触发器。

Step 4 – 在出现的下一个屏幕中，选择VCS trigger，它将用于创建触发器，以便在对存储库进行签入时，将触发构建。

步骤 5 – 单击显示高级选项并确保选择以下屏幕截图中显示的选项。

步骤 6 – 单击保存。您现在将看到触发器成功注册，如下面的屏幕截图所示。

第 7 步– 现在是时候将我们的代码签入 Git 存储库，看看会发生什么。所以让我们进入我们的命令提示符并发出git add命令来暂存我们更改的文件。

第 8 步– 现在发出git commit命令，它会将更改推送到 Git 存储库中。

第 9 步– 如果您现在转到“项目概览”屏幕，您现在将看到一个新的构建已被触发并运行。

如果您看到Change log Tab，您将看到触发构建的git 注释。

让我们再试一次。让我们对Demo.aspx文件进行另一个更改。让我们使用以下提交消息执行git add命令和git commit命令。

您现在将在 TeamCity 的项目仪表板中看到自动触发的构建。

构建将显示成功消息。

您现在将看到在将更改提交到git 存储库时使用的“第二次提交”消息。

我们现在已经成功完成了持续集成过程的第一部分。

CI – 构建失败通知

构建失败通知是在构建失败时触发的事件。每当构建失败时，都会向所有关键人员发送通知。在这种情况下要做的第一件事是确保将时间花在失败的构建上以确保构建通过。以下步骤用于确保在 TeamCity 中设置构建通知。

以下是在 TeamCity 中设置电子邮件通知的步骤。

步骤 1 – 在 TeamCity 中，转到您的项目仪表板，单击右上角的管理。然后，您将在左侧看到电子邮件通知程序链接。单击此链接可显示电子邮件的常规设置。

步骤 2 – 下一步是输入有效SMTP 服务器的详细信息。Gmail 提供免费的 SMTP 工具，任何人都可以使用。因此，我们可以在出现的下一个屏幕中输入这些详细信息，如下面的屏幕截图所示。

• SMTP 主机 – smtp.gmail.com
• SMTP 端口号 – 465
• 从 SMTP 登录发送电子邮件消息 – 这应该是一个有效的 Gmail id
• SMTP 密码 – 该 Gmail id 的有效密码
• 安全连接 – 将其设为 SSL

步骤 3 – 单击测试连接以确保设置正常工作。然后单击保存以保存设置。

Step 4 – 下一步是为用户启用构建通知。第一个任务是创建一个将接收这些构建通知的用户。转到您的项目仪表板并选择用户选项。

步骤 5 – 创建一个新用户。输入所需的用户名和密码。然后单击位于屏幕底部的创建用户按钮。

第 6 步– 现在使用此新用户 ID 和密码登录 TeamCity 系统。

步骤 7 – 登录后，您将看到用户的常规设置。在电子邮件通知程序部分，单击编辑。

步骤 8 – 在出现的下一个屏幕中，单击添加新规则。

步骤 9 – 在添加新规则中，选择以下两个选项，然后单击保存。

• 从选择项目构建 – 选择演示项目。

• 启用“构建失败”复选框。

通过启用这两个选项，现在每当 Demo 项目的构建失败时，都会向用户demouser发送电子邮件通知。

第 10 步– 现在让我们触发一个错误的构建来查看它的实际效果。在 Visual Studio 中，转到demo.aspx.cs文件并添加错误的代码行。

第 11 步– 现在通过执行git add和git commit从 Git 检入代码。

现在在项目仪表板中，构建将自动触发，您将看到构建将失败，如下面的屏幕截图所示。

如果您登录demouser的 Gmail id ，您实际上会在其中看到构建失败通知，如下面的屏幕截图所示。

CI – 文档和反馈

持续集成的关键方面之一始终是查看构建的执行情况、收集重要指标、记录这些结果并通过持续构建生成持续反馈。

制定这些指标有什么好处？

• Not Comitting Code Enough – 如果开发人员不经常将代码提交到版本控制存储库，原因可能是集成构建缓慢。要开始缩短构建持续时间，请对集成构建环境进行高级分析以确定瓶颈。

  接下来，分析发现并确定最合适的改进，然后尝试在构建过程中进行更改以减少构建的持续时间。最后，重新评估构建持续时间以确定是否需要进一步改进。

• 提高测试性能– 即使在运行良好的 CI 系统中，大部分集成构建时间也将被执行自动化测试占用。评估和改进这些测试的性能可以显着缩短构建持续时间。

• 基础设施问题– 您可能会发现由于系统基础设施，集成构建很慢。可能网络性能较慢或存在性能较慢的虚拟专用网络连接。

  地理上分散的系统和不可靠的硬件或软件也会导致性能问题。调查和改进任何基础设施资源以减少构建持续时间。

指标

以下是持续集成服务器中可用的一些指标。

让我们看看 TeamCity 必须提供什么 –

最简单的指标形式之一是项目仪表板中可用的指标。这里的关键要素是注意每个构建的持续时间。如果每次构建的持续时间开始与正在构建的代码不成比例地增加，那么这可能是一个问题。因此，这是可以采取的一种反馈，其原因可能是 CI 服务器资源不足，可能需要增加服务器的容量。

TeamCity 可以查看 CI 服务器实际上是否在基础架构方面存在任何类型的问题。在TeamCity的管理仪表板中，可以单击“磁盘使用情况”以查看每个构建消耗了多少磁盘空间。

如果需要更多详细信息，则 TeamCity 具有诊断按钮，它可以提供有关CI 服务器正在使用的CPU 和内存的更多信息。

构建指标的详细视图

如果想要查看特定项目随时间推移的构建的详细视图，则可以将其作为项目构建的一部分使用。在项目构建屏幕中，转到统计屏幕，这将提供有关构建执行情况的各种统计数据和图表。

持续集成 – 测试

持续集成的关键特性之一是确保正在进行的测试保存由 CI 服务器构建的所有代码。在 CI 服务器执行构建之后，必须确保测试用例到位以测试所需的代码。每个 CI 服务器都能够将单元测试用例作为CI 套件的一部分运行。在.Net 中，单元测试是内置在.Net 框架中的一项功能，同样的事情也可以合并到 CI 服务器中。

本章将看到我们如何在.Net 中定义一个测试用例，然后在构建完成后让我们的 TeamCity 服务器运行这个测试用例。为此，我们首先需要确保为示例项目定义了单元测试。

为此，我们必须非常小心地遵循随后的步骤。

第 1 步– 让我们向我们的解决方案添加一个新类，它将在我们的单元测试中使用。这个类将有一个名称变量，它将保存字符串“Continuous Integration”。该字符串将显示在网页上。右键单击 Simple Project 并选择菜单选项Add → Class。

第 2 步– 为类命名Tutorial.cs，然后单击屏幕底部的添加按钮。

第 3 步– 打开 Tutorial.cs 文件并在其中添加以下代码。此代码仅创建一个名为Name的字符串，并在构造函数中将该名称分配给一个字符串值作为持续集成。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      public Tutorial() {
         Name = "Continuous Integration";
      }
   }
}

第 4 步– 让我们更改Demo.aspx.cs文件以使用这个新类。使用以下代码更新此文件中的代码。所以这段代码现在将创建上面创建的类的一个新实例。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      protected void Page_Load(object sender, EventArgs e) {
         tp.Name = "Continuous Integration";
      }
   }
}

第5步-在我们的demo.aspx文件，现在让我们引用tp.Name变量，这是在创建aspx.cs文件。

<%@ Page Language = "C#" AutoEventWireup = "true" 
   CodeBehind = "Demo.aspx.cs" Inherits = "Simple.Demo" %>
<!DOCTYPE html>
<html xmlns = "http://www.w3.org/1999/xhtml">
   
   <head runat = "server">
      <title>TutorialsPoint1</title>
   </head>
   
   <body>
      <form id = "form1" runat = "server">
         <div>
            <% = tp.Name%>)
         </div>
      </form>
   </body>
   
</html>

为了确保我们的代码在这些更改中正常工作，您可以在 Visual Studio 中运行代码。编译完成后，您应该得到以下输出。

第 6 步– 现在是时候将我们的单元测试添加到项目中了。右键单击Solution并选择菜单选项Add → New Project。

Step 7 – 导航到Test并在右侧，选择Unit Test Project。将名称命名为DemoTest，然后单击“确定”。

步骤 8 – 在您的Demo Test 项目中，您需要添加对 Simple 项目和必要的测试程序集的引用。右键单击该项目并选择菜单选项Add Reference。

第 9 步– 在出现的下一个屏幕中，转到“项目”，选择“简单参考”并单击“确定”。

步骤 10 –再次单击添加引用，转到程序集并在搜索框中键入Web。然后添加System.Web的引用。

步骤 11 – 在单元测试文件中，添加以下代码。此代码将确保 Tutorial 类具有字符串名称变量。它还将断言名称应等于“持续集成”值的事实。这将是我们简单的测试用例。

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.VisualStudio.TestTools.UnitTesting.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Simple;

namespace DemoTest {
   [TestClass]
   public class UnitTest1 {
      [TestMethod]
      public void TestMethod1() {
         Tutorial tp = new Tutorial();
         Assert.AreEqual(tp.Name, "Continuous Integration");
      }
   }
}

第 12 步– 现在让我们在 Visual Studio 中运行我们的测试以确保它正常工作。在 Visual Studio 中，选择菜单选项Test → Run → All Tests。

运行测试后，您将在 Visual Studio 的左侧看到测试成功运行。

在 TeamCity 中启用持续测试 – 现在所有测试用例都已准备就绪，是时候将它们集成到我们的 Team City 服务器中了。

步骤 13 – 为此，我们需要在我们的项目配置中创建一个构建步骤。转到您的项目主页并单击编辑配置设置。

步骤 14 – 然后转到构建步骤 → MS 构建并单击添加构建步骤，如下面的屏幕截图所示。

在出现的下一个屏幕中，添加以下值 –

• 选择运行器类型作为 Visual Studio 测试。

• 输入可选的测试步骤名称。

• 选择测试引擎类型作为VSTest。

• 选择测试引擎版本为VSTest2013。

• 在测试文件名中，提供DemoTest\bin\Debug\DemoTest.dll 的位置– 请记住，DemoTest是包含我们的单元测试的项目的名称。该DemoTest.dll将由我们首先构建步骤产生。

• 单击屏幕末尾的“保存”。

现在，您的项目将有 2 个构建步骤。第一个是构建步骤，它将构建您的应用程序代码和您的测试项目。接下来将用于运行您的测试用例。

第 15 步– 现在是在 Git 中签入所有代码的时候了，以便可以触发整个构建过程。唯一的区别是这次，您需要从Demo 父文件夹运行git add和git commit命令，如下面的屏幕截图所示。

现在，当构建被触发时，您将看到一个初始输出，表明测试通过。

步骤 16 – 如果您单击测试通过结果并转到测试选项卡，您现在将看到 UnitTest1 已执行并通过。

持续集成 – 检查

持续检查是在运行实际测试之前对代码进行自动代码审查的过程。检查和测试软件之间存在细微差别。测试是动态的，执行软件以测试功能。检查根据一组预定义规则分析代码。

检查员（或静态和动态分析工具）由团队应遵守的已确定标准（通常是编码或设计指标）指导。检查目标的示例包括编码“语法”标准、架构分层依从性、代码重复等。

持续检查减少了发现和修复之间的时间。有许多连续检查工具可用。对于此示例，我们将使用与 TeamCity 集成的NCover 3.x。让我们看看如何进行持续检查以及它可以为我们做什么。

下载并安装 Ncover

NCover 是一个单独的产品，需要下载和安装。要下载 NCover，请单击以下链接并下载 32 位安装程序 – http://www.ncover.com/info/download。

运行下载的安装程序，然后在安装程序启动后单击下一步。

接受许可协议，然后单击下一步。

接受默认组件并单击下一步。

单击安装按钮开始安装。

单击完成按钮以完成安装。

通过转至C:\Program Files (x86)\NCover\ NCover.Explorer.exe首次启动 NCover 安装。您只需要第一次安装试用密钥，这是一个简单的过程。

在 TeamCity 中配置项目以使用 NCover

步骤 1 – 转到您的项目主屏幕，然后单击编辑配置设置。

Step 2 – 转到 Build Steps 并单击TestStep 的Edit 。持续检查需要与定义的单元测试一起运行。

步骤 3 – 在 .Net Coverage 部分，点击.Net Coverage Tool。然后选择以下设置。

• 选择 .Net Coverage 工具作为 NCover(3.x)
• 平台为 x86
• 版本为 v4.0
• NCover 的路径为 C:\Program Files (x86)\NCover
• 保持其他设置不变

步骤 4 – 单击保存。

第 5 步– 现在转到项目的主屏幕并单击运行。

步骤 6 – 运行构建后，单击测试通过。您现在将看到一个代码覆盖率屏幕，您将看到许多度量指标。

步骤 7 – 您现在可以单击代码覆盖率选项卡以获取有关代码分析的更多信息。

步骤 8 – 单击fullcoveragereport.html。您现在将获得一份关于对.Net 代码执行的检查的完整综合报告。

持续集成 – 数据库

持续数据库集成是在对项目的版本控制存储库应用更改时重建数据库和测试数据的过程。

在数据库集成中，通常所有与数据库集成相关的工件 –

• 应该驻留在版本控制系统中。
• 可以进行严格性测试和政策合规性检查。
• 可以使用您的构建脚本生成。

可以参与持续数据库集成的活动可以是以下任何一项 –

删除数据库– 删除数据库并删除关联的数据，以便您可以创建一个具有相同名称的新数据库

创建新数据库– 使用数据定义语言（DDL）创建新数据库。

插入初始数据– 插入您的系统在交付时预期包含的任何初始数据（例如，查找表）。

迁移数据库和数据– 定期迁移数据库架构和数据（如果您正在基于现有数据库创建系统）。

修改列属性– 根据需求和重构修改表列属性和约束。

修改测试数据– 根据需要更改多个环境的测试数据。

因此，在我们的连续数据库示例中，我们将执行以下步骤 –

• 我们将创建一个 MS SQL Server 数据库和一个相应的表。

• 我们将使用 SQL Server Management Studio 创建一个脚本。此数据库脚本将用于在数据库中设置我们的表。

• 我们将在我们的 ASP.Net 项目中编写一个代码来访问这个数据库。

• 我们将在 TeamCity 的项目中创建一个步骤来运行此脚本。

• 我们将把我们的脚本签入 Git。

在前面部分创建的 AWS 数据库中执行此操作的步骤。

步骤 1 – 创建 MS SQL Server 数据库和相应的表。让我们打开 SQL Server Management Studio 并创建一个简单的数据库和表。右键单击数据库，然后单击新建数据库。

第 2 步– 将其命名为Demodb，然后单击“确定”

步骤 3 – 在新数据库中，右键单击并创建一个新表。

步骤 4 – 您可以将所需的列添加到表中。

步骤 5 – 保存表并将其命名为Demotb。

步骤 6 – 现在右键单击表格并选择菜单选项Script Table as → Drop and Create to → File。

步骤 7 – 将文件作为Sample.sql保存到演示项目文件夹。

这就是数据库脚本的样子。它将首先删除现有表（如果存在），然后重新创建该表。

USE [Demodb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******

DROP TABLE [dbo].[Demotb]
GO

/****** Object: Table [dbo].[Demotb] Script Date: 3/22/2016 7:03:25 AM

******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Demotb](
   [TutorialName] [nvarchar](max) NULL,
   [TutorialID] [smallint] NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

GO

第 8 步– 现在让我们快速更改我们的ASP.Net 代码以引用新数据库。

步骤 9 – 在演示项目的Tutorial.cs文件中，添加以下代码行。这些代码行将连接到您的数据库，获取服务器版本并将版本名称存储在 Name 变量中。我们可以通过Response.write命令在我们的Demo.aspx.cs文件中显示这个 Name 变量。

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;

namespace Simple {
   public class Tutorial {
      public String Name;
      
      public Tutorial() {
         string connectionString = "Data Source = WIN-50GP30FGO75;
         Initial Catalog = Demodb;
         Integrated Security = true;";
         
         using (SqlConnection connection = new SqlConnection()) {
            connection.ConnectionString = connectionString;
            connection.Open();
            Name = connection.ServerVersion;
            connection.Close();
         }
      }
   }
}

步骤 10 – 将以下代码添加到Demo.aspx.cs文件以确保它显示 SQL Server 版本。

using System;
using System.Collections.Generic;
using System.Data.SqlClient;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace Simple {
   public partial class Demo : System.Web.UI.Page {
      Tutorial tp = new Tutorial();
      
      protected void Page_Load(object sender, EventArgs e){
         Response.Write(tp.Name);
      }
   }
}

现在，如果我们运行代码，您将在浏览器中获得以下输出。

步骤 11 – 现在让我们在 TeamCity 中添加我们的步骤，它将调用数据库脚本。转到您的项目仪表板并单击Edit Configuration Settings。

步骤 12 – 转到构建步骤并单击添加构建步骤。

选择以下选项（请注意，应在 CI 服务器上安装 MS SQL Server 客户端）。

• Runner 类型应该是命令行。

• 提供一个可选的步骤名称。

• 运行应该是带有参数的可执行文件。

• 命令可执行文件应该是C:\Program Files\Microsoft SQL Server\110\Tools\Binn\sqlcmd.exe

• 命令参数应为-S WIN-50GP30FGO75 -i Sample.sql。其中 -S 给出 SQL Server 实例的名称。

步骤 13 – 单击保存。

现在需要确保的是构建顺序。您必须确保构建顺序如下。

步骤 14 – 您可以通过选择重新排序构建步骤的选项来更改构建顺序。

• 数据库设置应该是第一 – 所以这将用于重新创建您的数据库。

• 接下来是构建您的应用程序。

• 最后你的测试设置。

第 15 步– 现在运行git add和git commit命令，以便将Sample.sql文件签入 Git。这将自动触发构建。这个构建应该通过。

您现在拥有一个完整的构建周期，在您的周期中也有持续的数据库集成方面。在下一节中，让我们进一步了解持续部署。

现在您已使用本地 SQL Server 完成此操作，我们可以对在前面部分中创建的AWS MS SQL Server重复相同的步骤。要连接到 Microsoft SQL Server，您需要通过以下约定进行连接。

第 16 步– 首先查看在 AWS 中分配给您的数据库实例的名称是什么。登录AWS后，进入数据库部分下的RDS部分。

步骤 17 – 在出现的下一个屏幕中单击数据库实例。

步骤 18 – 单击您的数据库并记下端点。在下面的截图中，它是demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com:1433

步骤 19 – 现在要从SQL Server Management Studio连接到数据库，您需要将连接指定为demodb.cypphcv1d87e.ap-southeast-1.rds.amazonaws.com,1433（注意实例名称和端口号之间使用的逗号）。

以下屏幕截图显示了与数据库的成功连接。

然后您可以重复所有相同的步骤。该SQLCMD命令将作如下-

可以在 TeamCity 的数据库构建步骤中替换相同的命令。当您执行sqlcmd 命令时，该表将在您在 AWS 中的 SQL Server 数据库中自动创建。

持续集成 – 部署

自动化构建和可重复构建。自动化测试和可重复测试。测试类别和测试频率。持续检查。持续的数据库集成。创建有效 CI 环境的这一系列任务主要实现了一个关键优势：在任何时间点、任何环境中发布可工作的软件。

在我们之前的章节中，我们已经完成了以下所有部分 –

• 创建了我们的代码。
• 确保在 TeamCity 中正确构建。
• 创建了一个数据库集成过程。
• 进行了成功的测试。

现在剩下的就是进行一次自动化部署，这样我们的整个流程就完成了。

对于我们案例中的自动化部署，我们需要遵循以下步骤 –

• 在我们的部署服务器中，确保安装了 IIS。

• 确保 IIS 用户有权访问我们的数据库。

• 创建一个发布配置文件，用于在构建站点时发布站点。

• 确保我们更改 MSBuild 命令以进行自动部署。

• 自动化 TeamCity 以进行自动发布。

• 执行git commit以确保所有文件都在 Git 中。

步骤 1 – 配置本地 IIS 服务器。如果您有本地或远程 IIS 服务器，则可以进行以下配置来部署我们的应用程序。在以自动化方式完成部署之前，先看看是否可以手动完成部署，这始终是一个好习惯。

步骤 2 – 在 Windows 2012 服务器上，转到服务器管理器并单击添加角色和功能。

步骤 3 – 在出现的以下屏幕上单击下一步。

步骤 4 – 在下一个屏幕上选择基于角色或基于功能的安装，然后单击下一步。

步骤 5 – 选择默认服务器并单击下一步。

步骤 6 – 选择 Web 服务器角色，然后单击下一步。

步骤 7 – 在出现的下一个屏幕中，单击下一步。

步骤 8 – 在出现的以下屏幕上再次单击下一步。

步骤 9 – 在弹出的下一个屏幕中，单击下一步。

步骤 10 – 在最后一个屏幕中，您可以单击安装按钮来安装 IIS。

安装 IIS 后，您可以通过打开 Internet 信息服务来打开它。

步骤 11 – 单击应用程序池，您将看到一个名为DefaultAppPool的池。这需要在下一步中访问 SQL Server。

第 12 步– 如果我们需要将 ASP.Net 应用程序连接到 MS SQL Server 应用程序，我们必须将默认应用程序池的访问权限授予 SQL Server 实例，以便它可以连接到我们的Demodb数据库。

步骤 13 – 打开 SQL Server Management Studio。转到登录，右键单击并选择菜单选项New Login。

在下一个屏幕中，更新以下参数并单击确定。

• 登录名作为 IIS APPPOOL\DefaultAppPool。
• 默认数据库 – 这应该是我们的数据库，即 demodb。

步骤 14 – 创建发布配置文件。发布配置文件在 Visual Studio 中用于创建一个部署包，然后可以与 MS Build 和任何 CI 服务器相应地使用该包。为此，在 Visual Studio 中，右键单击该项目，然后单击“发布”菜单选项

步骤 15 – 在出现的下一个屏幕中，选择创建一个新的发布配置文件，并为其命名 – DemoDeployment。然后单击下一步按钮。

在随后出现的屏幕中，添加以下值 –

• 选择发布方法作为 Web 部署。
• 输入服务器作为本地主机。
• 输入站点名称作为默认网站/演示。
• 将目标 url 设为http://localhost/Demo

然后单击下一步按钮。

步骤 16 – 在下一个屏幕中，单击下一步。

步骤 17 – 在出现的最后一个屏幕中，单击“发布”按钮。

现在，如果您转到项目的C:\Demo\Simple\Properties\PublishProfiles位置，您将看到创建的新发布配置文件 xml 文件。此发布配置文件将包含将应用程序发布到本地 IIS 服务器所需的所有详细信息。

第 18 步– 现在让我们自定义我们的 MSBuild 命令并使用上面的发布配置文件，看看会发生什么。在我们的 MSBuild 命令中，我们指定以下参数 –

• Deploy on Build 为 true – 一旦构建成功，这将触发自动部署。

• 然后我们提到使用在上述步骤中使用的发布配置文件。

• Visual Studio 版本只是在 MSBuild 部署功能中提及正在使用的 Visual Studio 版本。

当您运行上述命令时，MSBuild 将触发构建和部署过程。您会注意到，它正在将其部署到我们 IIS 服务器中的默认网站。

现在，如果我们浏览到该站点 – http://localhost/Demo/Demo.aspx，我们将看到以下输出，这意味着 MSBuild 已成功部署到我们的网站。

第 19 步– 通过 TeamCity 实现自动化——现在是时候向我们的 TeamCity 服务器添加一个任务，以根据上述步骤自动使用 MSBuild 部署我们的应用程序。

步骤 20 – 转到您的项目仪表板，然后单击编辑配置设置。

步骤 21 – 转到构建步骤并单击添加构建步骤。

选择以下选项 –

• 跑步者类型应该是 MSBuild

• 给一个可选的步骤名称

• 将构建路径输入为 Simple/Simple.csproj

• 将 MSBuild 版本保留为 Microsoft Build Tools 2013

• 保持 MSBuild 工具版本为 12.0

• 将命令行设置为 /p:DeployOnBuild = true /p:PublishProfile = DemoDeployement /p:VisualStudioVersion = 12.0

步骤 22 – 单击保存。

确保在构建步骤中，部署步骤是链中的最后一步。

步骤 23 – 现在让我们做一个最终的git commit，以确保所有文件都在 Git 中并且可以被 TeamCity 使用。

恭喜，您已经成功为您的应用程序设置了一个完整的持续集成周期，该周期可以在任何时间点运行。

持续集成 – 最佳实践

让我们根据迄今为止学到的所有经验教训对持续集成的最佳实践进行最终审查 –

• 维护代码存储库– 这是最基本的步骤。在我们所有的示例中，从代码库到发布配置文件，再到数据库脚本，所有内容都保存在 Git 存储库中。必须始终确保所有内容都保存在代码存储库中。

• 自动化构建– 我们已经看到了如何使用 MSBuild 来自动化构建以及使用发布配置文件。这又是持续集成过程中的关键步骤。

• Make the build self-testing – 确保您可以通过保持单元测试用例来测试构建，并且这些测试用例应该以这样的方式可以由持续集成服务器运行。

• 每个人每天都致力于基线– 这是持续集成的关键原则。没有必要等到整个过程结束才能查看谁破坏了构建。

• 应该构建每个提交（到基线） – 对应用程序所做的每个提交，都需要成功构建。如果构建因任何原因失败，则需要更改代码以确保构建通过。

• 保持快速构建– 如果构建缓慢，则表明整个持续集成过程中存在问题。确保构建始终限于持续时间，最好不要超过 10 分钟。

• 每个人都可以看到最新构建的结果– TeamCity 仪表板为每个人提供了所有构建的视图，这些构建要么通过，要么失败。这为参与持续集成过程的所有人员提供了很好的洞察力。