持续集成 - 快速指南
持续集成 - 概述
持续集成 (Continuous Integration) 最初于 2000 年随着名为 **Cruise Control** 的软件的出现而被引入。多年来，持续集成已成为任何软件组织中的关键实践。这是一种开发实践，它要求开发团队确保对软件程序的每次代码更改都进行构建和后续测试。这个概念旨在解决在构建生命周期中后期发现问题的难题。持续集成的引入是为了确保代码更改和构建不会孤立地进行，而不是让开发人员孤立地工作且集成不足。
为什么要持续集成？
持续集成已成为任何软件开发流程中非常重要的组成部分。持续集成流程帮助软件开发团队解答以下问题。
所有软件组件是否按预期协同工作？– 有时系统会变得非常复杂，每个组件都有多个接口。在这种情况下，确保所有软件组件都能无缝协同工作始终至关重要。
代码是否过于复杂而无法集成？– 如果持续集成流程持续失败，则可能表示代码过于复杂。这可能是一个信号，表明需要应用适当的设计模式来使代码更简洁、更易于维护。
代码是否符合既定的编码标准？– 大多数测试用例始终会检查代码是否符合正确的编码标准。通过在自动构建后进行自动测试，这是一个检查代码是否满足所有所需编码标准的好时机。
自动化测试涵盖了多少代码？– 如果测试用例没有涵盖代码的所需功能，那么测试代码毫无意义。因此，始终应该确保编写的测试用例涵盖应用程序的所有关键场景。
最新更改后所有测试是否都成功？– 如果测试失败，则没有必要继续部署代码，因此这是一个检查代码是否准备好进入部署阶段的好时机。
工作流程
下图快速展示了任何软件开发项目中整个持续集成工作流程的工作方式。我们将在后续章节中详细介绍这一点。
因此，根据上述工作流程，持续集成流程通常的工作方式如下。
首先，开发人员将代码提交到版本控制存储库。同时，集成构建机器上的持续集成服务器轮询源代码存储库以查找更改（例如，每隔几分钟）。
提交发生后不久，持续集成服务器检测到版本控制存储库中发生了更改，因此持续集成服务器从存储库检索代码的最新副本，然后执行构建脚本，该脚本集成软件。
持续集成服务器通过向指定的项目成员发送电子邮件的方式生成反馈。
如果该项目的构建通过，则执行单元测试。如果测试成功，则代码已准备好部署到暂存服务器或生产服务器。
持续集成服务器继续轮询版本控制存储库中的更改，整个过程重复进行。
持续集成 - 软件
软件部分是任何持续集成流程中最重要的方面。本章重点介绍整个持续集成流程所需的软件。
源代码存储库
源代码存储库用于维护所有源代码及其所有更改。两种最流行的源代码存储库管理工具是 Subversion 和 Git，其中 Git 是最近最流行的系统。我们现在来看一下如何在系统上安装 Git。
系统要求
| 内存 | 2 GB RAM（推荐） |
| 磁盘空间 | 安装需要 200 MB HDD。需要额外的存储空间来存储项目源代码，这取决于添加的源代码量。 |
| 操作系统版本 | 可在 Windows、Ubuntu/Debian、Red Hat/Fedora/CentOS、Mac OS X 上安装。 |
安装 Git
**步骤 1** - Git 的官方网站是 https://git-scm.cn/。单击链接后，您将进入 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** - 在以下屏幕中，接受“签出 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. Ltd. 公司提供的另一款流行的持续集成软件。
上述所有软件都使用相同的持续集成模型。在本教程中，我们将以 **Jetbrains TeamCity** 作为持续集成服务器。
安装 TeamCity
以下是您在计算机上安装 Jet Brains TeamCity 的步骤和系统要求。
系统要求
| 内存 | 4 GB RAM（推荐） |
| 磁盘空间 | 安装需要 1 GB HDD。需要额外的存储空间来存储每个项目的构建工作区。 |
| 操作系统版本 | 可在 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 工件的数据库。在本教程中，可以选择 **内部 (HSQLDB)**，这是在使用产品进行测试时最适合的内部数据库。
然后，TeamCity 将处理所有必要的步骤以使其启动并运行。
**步骤 3** - 接下来，您将被要求接受许可协议。接受并单击“继续”。
**步骤 4** - 您需要创建一个管理员帐户，该帐户将用于登录 TeamCity 软件。输入所需详细信息，然后单击“创建帐户”按钮。
您现在将登录 TeamCity。
构建工具
构建工具是一种确保程序以特定方式构建的工具。该工具通常会执行一系列任务，这些任务是程序以正确方式构建所必需的。由于在我们的示例中，我们将研究一个.Net程序，因此我们将MSBuild视为构建工具。MSBuild工具查看包含用于构建项目的任务列表的构建文件。让我们来看一个Web配置项目的典型构建文件。
以下是需要考虑的构建文件的主要部分。
IIS设置
以下设置用于确定端口号、Web服务器上的路径以及应用程序运行时所需的认证类型。这些是重要的设置，当我们稍后在教程中学习如何执行部署时，将通过MSBuild命令更改这些设置。
<UseIIS>True</UseIIS> <AutoAssignPort>True</AutoAssignPor> <DevelopmentServerPort>61581</DevelopmentServerPort> <DevelopmentServerVPath>/</DevelopmentServerVPath> <IISUrl>https://:61581/</IISUrl> <NTLMAuthentication>False</NTLMAuthentication>
ItemGroup
这用于告诉构建服务器运行此项目所需的所有依赖二进制文件。
<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 Framework版本
TargetFrameworkVersion 指明项目运行所需的.Net版本。这是绝对必要的，因为如果构建服务器没有安装此版本，则构建将失败。
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
部署环境 – Amazon
在本教程中，我们将确保我们的持续集成服务器能够将我们的应用程序部署到Amazon。为此，我们需要确保以下工件已到位。
数据库服务器
执行以下步骤以确保在Amazon中为部署准备数据库服务器。
步骤1 − 转到Amazon控制台 − https://aws.amazon.com/console/.
使用您的凭据登录。请注意，您可以申请Amazon网站上的免费ID，这将允许您获得免费层级，使您可以免费使用Amazon上的一些资源。
步骤2 − 转到RDS部分以创建您的数据库。
步骤3 − 在下一个弹出的屏幕中点击“实例”。
步骤4 − 在下一个弹出的屏幕中点击启动数据库选项。
步骤5 − 选择SQL Server选项卡，然后为SQL Server Express选择“选择”选项。
步骤6 − 确保输入以下详细信息以确认您正在使用Amazon提供的免费层级的数据库。
步骤7 − 所有字段都填写完毕后，点击“下一步”按钮。
步骤8 − 在下一个弹出的屏幕中，接受所有默认设置，然后点击启动数据库实例。
步骤9 − 然后您将看到一个屏幕，显示数据库正在成功启动。在同一页面上，将有一个按钮用于查看数据库实例。点击链接查看您的数据库实例正在设置。
一段时间后，上述屏幕的状态将更改为通知数据库实例已成功创建。
Web服务器
下一步是在Amazon上创建您的Web服务器，该服务器将托管Web应用程序。这可以通过按照后续步骤来完成。
步骤1 − 转到Amazon控制台 − https://aws.amazon.com/console/.
使用您的凭据登录。请注意，您可以申请Amazon网站上的免费ID，这将允许您获得免费层级，使您可以免费使用Amazon上的一些资源。
步骤2 − 转到EC2部分以创建您的Web服务器。
步骤3 − 在下一个屏幕中，点击“启动实例”。
步骤4 − 点击Windows – Microsoft Windows Server 2010 R2 Base。
步骤5 − 选择t2.micro选项，这是免费层级的一部分。点击下一步：配置实例详细信息。
步骤6 − 接受下一个弹出的屏幕上的默认设置，然后选择下一步：添加存储选项。
步骤7 − 接受下一个屏幕上的默认设置，然后选择下一步：标记实例选项。
步骤8 − 接受下一个屏幕上的默认设置，然后选择下一步：配置安全组选项。
步骤9 − 接受下一个屏幕上的默认设置，然后选择查看并启动选项。
步骤10 − 在下一个弹出的屏幕中点击“启动”。
步骤11 − 在下一个弹出的屏幕中，系统将提示您创建一个密钥对。这将用于稍后登录服务器。只需创建密钥对并点击启动实例。
实例现在将在Amazon中设置。
持续集成 - 降低风险
项目可能会出现问题。通过有效地实践CI，您可以了解在开发过程中的每一步都会发生什么，而不是在项目进入开发周期后期才发现。CI帮助您在问题发生时识别和减轻风险，使您可以根据具体证据更容易地评估和报告项目的健康状况。
本节将重点关注使用持续集成可以避免的风险。
任何项目都需要管理许多风险。通过在开发生命周期的早期消除风险，这些风险在系统实际上线时发展成问题的可能性就会降低。
风险1 – 缺乏可部署的软件
“在我的机器上运行正常，但在其他机器上却不行” – 这可能是任何软件组织中最常见的短语之一。由于每天对软件构建进行的更改数量众多，有时人们对软件构建是否真正有效缺乏信心。此问题具有以下三种副作用。
对我们是否能够构建软件缺乏或没有信心。
在内部（即测试团队）或外部（即客户）交付软件之前，集成阶段漫长，在此期间没有其他工作完成。
无法生成和重现可测试的构建。
解决方案
消除IDE和构建过程之间的紧密耦合。使用单独的机器专门用于集成软件。确保构建软件所需的一切都包含在版本控制存储库中。最后，创建一个持续集成系统。
持续集成服务器可以监视版本控制存储库中的更改，并在检测到对存储库的更改时运行项目构建脚本。持续集成系统的能力可以增强，包括让构建运行测试、执行检查和在开发和测试环境中部署软件；这样您将始终拥有一个可工作的软件。
“无法与数据库同步” – 有时开发人员无法在开发过程中快速重新创建数据库，因此难以进行更改。这通常是由于数据库团队和开发团队之间的分离造成的。每个团队都将专注于自己的职责，彼此之间几乎没有合作。此问题具有以下三种副作用：
害怕更改或重构数据库或源代码。
难以使用不同的测试数据集填充数据库。
难以维护开发和测试环境（例如，开发、集成、QA和测试）。
解决方案
解决上述问题的办法是确保将所有数据库工件放入版本控制存储库中。这意味着重新创建数据库模式和数据所需的一切：数据库创建脚本、数据操作脚本、存储过程、触发器以及任何其他数据库资产都是必需的。
通过删除和重新创建数据库和表，从构建脚本中重新构建数据库和数据。接下来，应用存储过程和触发器，最后插入测试数据。
测试（和检查）您的数据库。通常，您将使用组件测试来测试数据库和数据。在某些情况下，您需要编写特定于数据库的测试。
风险2 – 在生命周期后期发现缺陷
由于多个开发人员频繁对源代码进行许多更改，因此代码中始终可能引入缺陷，这些缺陷可能只能在后期阶段检测到。在这种情况下，这可能会造成很大的影响，因为在软件中检测到的缺陷越晚，消除缺陷的成本就越高。
解决方案
回归测试 − 这是任何软件开发周期中最重要的方面，反复测试。如果对软件代码进行任何重大更改，则绝对必须确保运行所有测试。这可以通过持续集成服务器实现自动化。
测试覆盖率 − 如果测试用例没有涵盖代码的全部功能，则测试毫无意义。务必确保创建的用于测试应用程序的测试用例是完整的，并且所有代码路径都经过测试。
例如，如果您有一个需要测试的登录屏幕，您不能只进行成功登录的测试用例。您需要有一个负面测试用例，其中用户输入不同的用户名和密码组合，然后需要查看在这种情况下会发生什么。
风险3 – 缺乏项目可见性
手动沟通机制需要大量的协调才能确保及时地将项目信息传播给合适的人员。向旁边的开发人员倾斜并让他们知道最新的构建在共享驱动器上是相当有效的，但它并不具有很好的可扩展性。
如果其他开发者也需要这些信息，而他们正在休息或暂时无法联系怎么办？如果服务器宕机，你会如何收到通知？有些人认为可以通过手动发送电子邮件来降低这种风险。但是，这并不能保证信息在正确的时间传达给正确的人，因为你可能会意外地漏掉相关人员，而且有些人可能当时无法访问他们的电子邮件。
解决方案
这个问题的解决方案仍然是持续集成服务器。所有CI服务器都具有在构建失败时自动触发电子邮件的功能。通过向所有关键利益相关者自动发送通知，还可以确保每个人都了解软件的当前状态。
风险4 – 低质量软件
有缺陷，也有潜在缺陷。当你的软件设计不完善，或者不符合项目标准，或者难以维护时，你可能会遇到潜在缺陷。有时人们将其称为代码或设计异味——“暗示可能存在问题的症状”。
有些人认为低质量软件仅仅是推迟的项目成本（交付后）。它可以是推迟的项目成本，但它也会在将软件交付给用户之前导致许多其他问题。过于复杂的代码、不遵循架构的代码和重复的代码——通常都会导致软件缺陷。在这些代码和设计异味演变成缺陷之前发现它们可以节省时间和金钱，并可以提高软件质量。
解决方案
有一些软件组件可以执行代码质量检查，这些组件可以与CI软件集成。这可以在代码构建后运行，以确保代码实际符合正确的编码指南。
持续集成 - 版本控制
版本控制系统，也称为源代码控制、源代码管理系统或修订控制系统，是一种保存多个文件版本的方法，这样当你修改文件时，你仍然可以访问以前的修订版本。
第一个流行的版本控制系统是一个专有的UNIX工具，称为SCCS（源代码控制系统），它可以追溯到20世纪70年代。它后来被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>
代码非常简单，只需将字符串“持续集成”输出到浏览器。
当你在Google Chrome中运行项目时，输出将如下图所示。
将源代码移动到Git
我们将展示如何通过命令行界面将源代码移动到Git，以便最终用户更清楚地了解如何使用Git。
步骤1 − 初始化Git存储库。转到命令提示符，转到你的项目文件夹，然后发出命令git init。此命令将把必要的Git文件添加到项目文件夹中，以便Git在需要将其上传到存储库时能够识别它。
步骤2 − 添加需要添加到Git存储库的文件。这可以通过发出git add命令来完成。点选项告诉Git需要将项目文件夹中的所有文件添加到Git存储库。
步骤3 − 最后一步是将项目文件提交到Git存储库。此步骤是确保所有文件现在都是Git的一部分所必需的。要发出的命令在下面的屏幕截图中给出。–m选项用于向文件的上传提供注释。
你的解决方案现在可以在Git中使用了。
持续集成 - 功能
以下是持续集成的一些主要功能或实践。
维护单个源代码存储库 − 所有源代码都维护在一个存储库中。这避免了源代码分散在多个位置。诸如Subversion和Git之类的工具是维护源代码最流行的工具。
自动化构建 − 软件的构建应该以可以自动化的方式进行。如果需要执行多个步骤，则构建工具需要能够执行此操作。对于.Net，MSBuild是默认的构建工具，对于基于Java的应用程序，你拥有诸如Maven和Grunt之类的工具。
使你的构建可自测 − 构建应该是可测试的。构建直接发生后，应该运行测试用例以确保可以针对软件的各种功能进行测试。
每次提交都应该在集成机器上构建 − 集成机器是构建服务器，应该确保构建在此机器上运行。这意味着所有依赖组件都应该存在于持续集成服务器上。
保持构建速度快 − 构建应该在几分钟内完成。构建不应该花费数小时才能完成，因为这意味着构建步骤配置不正确。
在生产环境的克隆中进行测试 − 构建环境应该与生产环境的性质接近。如果这些环境之间存在巨大差异，则可能会出现构建在生产环境中失败而构建服务器上通过的情况。
每个人都可以看到正在发生的事情 − 构建、测试和部署的整个过程应该对所有人可见。
自动化部署 − 持续集成导致持续部署。绝对有必要确保构建易于部署到登台环境或生产环境。
持续集成 - 需求
以下是持续集成最重要的需求列表。
定期签入 − 持续集成正常工作的最重要实践是频繁签入源代码存储库的主干或主线。代码的签入应该每天至少进行几次。定期签入带来了许多其他好处。它使更改更小，因此不太可能破坏构建。这意味着当在任何后续构建中出现错误时，可以知道软件的最新版本。
它还有助于更严格地进行代码重构并坚持保留行为的小更改。它有助于确保更改大量文件的可能性较小与其他人的工作冲突。它允许开发人员更具探索性，尝试想法并通过恢复到上次提交的版本来丢弃它们。
创建一个全面的自动化测试套件 − 如果没有全面的自动化测试套件，通过构建仅意味着应用程序可以编译和组装。虽然对于一些团队来说，这是一个巨大的进步，但拥有某种程度的自动化测试以增强对应用程序实际工作的信心至关重要。
通常，在持续集成中进行3种类型的测试，即单元测试、组件测试和验收测试。
单元测试旨在单独测试应用程序的小部分行为。它们通常可以在不启动整个应用程序的情况下运行。它们不会访问数据库（如果你的应用程序有数据库）、文件系统或网络。它们不需要你的应用程序在类似生产的环境中运行。单元测试应该运行得非常快——即使对于大型应用程序，你的整个套件也应该能够在十分钟内运行。
组件测试测试应用程序的几个组件的行为。与单元测试一样，它们并不总是需要启动整个应用程序。但是，它们可能会访问数据库、文件系统或其他系统（这些系统可能是存根的）。组件测试通常需要更长时间才能运行。
保持构建和测试过程简短 − 如果构建代码和运行单元测试花费的时间太长，你将遇到以下问题。
人们将停止进行完整的构建，而会在签入前运行测试。你将开始出现更多失败的构建。
持续集成过程耗时很长，以至于在你再次运行构建之前可能已经进行了多次提交，因此你无法知道哪个检入破坏了构建。
人们会减少检入频率，因为他们必须等待很长时间才能完成软件构建和测试运行。
不要在构建中断时检入 − 持续集成的最大错误是在构建中断时检入。如果构建中断，则相关的开发人员将等待修复它。他们尽快找出中断的原因并进行修复。如果我们采用这种策略，我们将始终处于最佳位置来找出导致中断的原因并立即修复它。
如果我们的同事进行了检入并因此破坏了构建，那么为了最大限度地修复它，他们需要清晰地解决这个问题。当违反此规则时，构建修复的时间不可避免地会长得多。人们习惯了看到构建中断，很快就会出现构建一直中断的情况。
在提交之前始终在本地运行所有提交测试 − 始终确保首先在本地机器上运行为应用程序设计的测试，然后再在 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>
关于上述代码，需要注意以下几个方面：
使用名为 Build 的名称指定目标。其中，目标是在构建过程中需要执行的一系列逻辑步骤。您可以拥有多个目标，并且目标之间存在依赖关系。
在我们的目标中，我们保留一个选项消息，该消息将在构建过程启动时显示。
MSBuild 任务用于指定需要构建哪个 .Net 项目。
以上示例是一个非常简单的构建文件的案例。在持续集成中，确保此文件保持最新状态，以确保整个构建过程无缝进行。
在 .Net 中构建解决方案
.Net 的默认构建工具是 MSBuild，它随 .Net framework 一起提供。根据您系统上的框架，您将拥有相关的 MSbuild 版本。例如，如果您在默认位置安装了 .Net framework，则会在以下位置找到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 文件的某些方面，看看它们是什么意思。从持续集成周期的角度来看，了解这些方面非常重要。
构建脚本用于构建解决方案，该解决方案将成为整个持续集成周期的一部分。让我们看一下在我们的示例解决方案中作为 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命令执行此操作，如下面的屏幕截图所示。‘.’ 符号用于表示目录和子目录中的所有文件都应包含在提交中。
步骤 3 − 最后一步是将文件提交到 Git 存储库，以便它现在成为一个完整的 Git 存储库。
CI - 在 TeamCity 中创建项目
现在我们的源代码位于 Git 存储库中，并且我们所有的初始代码都在构建服务器上运行，现在是时候在我们的持续集成服务器中创建一个项目了。这可以通过以下步骤完成：
步骤 1 − 登录到 TeamCity 软件。转到持续集成服务器上的 url −https://:8080/login.html。
输入管理员凭据并登录到服务器。
步骤 2 − 登录后，您将看到主屏幕。单击创建项目以启动新项目。
步骤 3 − 为项目命名，然后单击创建以启动项目。在我们的案例中，我们为项目命名为“Demo”，如下面的屏幕截图所示。
步骤 4 − 下一步是提及项目中将使用的 Git 存储库。请记住，在持续集成环境中，CI 服务器需要从 Git 启用的存储库中获取代码。我们已经在之前的步骤中启用了我们的项目文件夹作为 Git 启用的存储库。在 TeamCity 中，您需要创建一个 VCS 根。为此，请单击项目主屏幕中的VCS 根。
步骤 5 − 在接下来出现的屏幕中，单击创建 VCS 根，如下面的屏幕截图所示。
步骤 6 − 在接下来出现的屏幕中，执行以下步骤：
将 VCS 类型提及为 Git。
为 VCS 根命名，这可以是任何友好的名称。我们将其命名为App。
将 Fetch url 指定为C:\Demo\Simple – 这是我们git启用的存储库。
如果向下滚动屏幕，您将看到一个测试连接按钮。单击它以确保您可以成功连接到 Git 启用的存储库。
步骤 7 − 单击创建，您现在将看到您的存储库已注册，如下面的图像所示。
步骤 8 − 下一步是创建一个构建配置，该配置将用于构建项目。转到 TeamCity 中的项目屏幕→常规设置。单击创建构建配置。
步骤 9 − 在以下屏幕中，为构建配置命名。在我们的案例中，我们将其命名为DemoBuild，然后单击创建。
步骤 10 − 在接下来出现的屏幕中，系统将要求您选择在前面步骤中创建的VCS 存储库。因此，选择名称“App”并单击附加。
步骤 11 − 现在在弹出的下一个屏幕中，我们需要配置构建步骤。因此，单击“手动配置构建步骤”超链接。
步骤 12 − 在下一个构建屏幕中，我们需要输入以下详细信息：
选择运行程序类型为 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 − 转到您的项目仪表板，单击触发器部分，然后单击添加新的触发器。
步骤 4 − 在出现的下一个屏幕中，选择VCS 触发器，这将用于创建一个触发器，以便在对存储库进行签入时触发构建。
步骤 5 − 单击显示高级选项，并确保选择了以下屏幕截图中显示的选项。
步骤 6 − 单击保存。您现在将看到触发器已成功注册，如下面的屏幕截图所示。
步骤 7 − 现在是时候将我们的代码签入 Git 存储库并查看会发生什么了。因此，让我们转到命令提示符并发出git add命令来暂存我们更改的文件。
步骤 8 − 现在发出git commit命令，它会将更改推送到 Git 存储库。
步骤 9 − 如果您现在转到“项目概述”屏幕，您将看到一个新的构建已被触发并运行。
如果您看到更改日志选项卡，您将看到触发构建的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 − 单击测试连接以确保设置正常工作。然后单击保存以保存设置。
步骤 4 − 下一步是为用户启用构建通知。第一个任务是创建一个将接收这些构建通知的用户。转到您的项目仪表板并选择用户选项。
步骤 5 − 创建一个新用户。输入所需的用户名和密码。然后单击“创建用户”按钮，该按钮位于屏幕底部。
步骤 6 − 现在使用此新的用户 ID 和密码登录 TeamCity 系统。
步骤 7 − 登录后，您将看到用户的常规设置。在“电子邮件通知程序”部分中，单击“编辑”。
步骤 8 − 在出现的下一个屏幕中，单击添加新规则。
步骤 9 − 在“添加新规则”中，选择以下两个选项，然后单击“保存”。
来自所选项目的构建 – 选择 Demo 项目。
选中“构建失败”复选框。
通过启用这两个选项，现在每当 Demo 项目的构建失败时，都会向用户demouser发送电子邮件通知。
步骤 10 − 现在让我们触发一个错误构建以查看其运行情况。在 Visual Studio 中，转到demo.aspx.cs文件并添加错误的代码行。
步骤 11 − 现在通过执行git add和git commit从 Git 中签入代码。
现在在项目仪表板中，构建将自动触发，您将看到构建失败，如下面的屏幕截图所示。
如果您登录demouser的 Gmail ID，您实际上会在其中看到构建失败通知，如下面的屏幕截图所示。
CI - 文档和反馈
持续集成的关键方面之一是始终查看构建的执行情况，收集重要的指标，记录这些结果并通过持续构建生成持续反馈。
实施这些指标的好处是什么？
代码提交不足 − 如果开发人员不经常将代码提交到版本控制存储库，原因可能是集成构建速度慢。要开始减少构建持续时间，请对集成构建环境进行高级分析以确定瓶颈。
接下来，分析调查结果并确定最合适的改进方法，然后尝试更改构建过程以减少构建的持续时间。最后，重新评估构建持续时间以确定是否需要进一步改进。
改进测试性能 − 即使在运行良好的 CI 系统中，集成构建时间的很大一部分也将用于执行自动化测试。评估和改进这些测试的性能可以大大减少构建持续时间。
基础设施问题 − 您可能会发现集成构建速度慢是因为系统基础设施。也许网络性能缓慢，或者虚拟专用网络连接性能缓慢。
地理位置分散的系统和不可靠的硬件或软件也可能导致性能问题。调查并改进任何基础设施资源以减少构建持续时间。
指标
以下是持续集成服务器中提供的一些指标。
让我们看看 TeamCity 提供了什么：
最简单的指标形式之一是项目仪表板中提供的指标。这里的关键因素是要注意每次构建的持续时间。如果每次构建的持续时间开始不成比例地增加到正在构建的代码，那么这可能是一个问题。因此，这是一个可以获取的反馈，其原因可能是 CI 服务器资源不足，可能需要增加服务器容量。
TeamCity 具有查看 CI 服务器是否确实存在任何基础设施问题的功能。在 TeamCity 的管理员仪表板中，可以单击磁盘使用情况以查看每次构建使用了多少磁盘空间。
如果需要更多详细信息，则 TeamCity 具有诊断按钮，该按钮可以提供有关 CI 服务器使用的CPU 和内存的更多信息。
构建指标的详细视图
如果要查看一段时间内特定项目的构建的详细视图，则可以在项目构建中使用此功能。在项目构建屏幕中，转到“统计”屏幕，这将提供关于构建性能的各种统计数据和图表。
持续集成 - 测试
持续集成的关键功能之一是确保持续测试包含 CI 服务器构建的所有代码。CI 服务器执行构建后，必须确保测试用例到位以对所需的代码进行测试。每个 CI 服务器都能够在CI 套件中运行单元测试用例。在.Net中，单元测试是内置于.Net 框架中的功能，并且可以将其整合到 CI 服务器中。
本章将介绍如何在.Net中定义测试用例，然后在构建完成后让我们的 TeamCity 服务器运行此测试用例。为此，我们首先需要确保为我们的示例项目定义了单元测试。
为此，我们必须以最大的谨慎遵循以下步骤。
步骤 1 − 让我们向我们的解决方案添加一个新类，这将在我们的单元测试中使用。此类将具有一个名称变量，该变量将保存字符串“持续集成”。此字符串将显示在网页上。右键单击 Simple 项目并选择菜单选项添加→类。
步骤 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 − 现在是时候向项目添加单元测试了。右键单击解决方案，然后选择菜单选项添加→新项目。
步骤 7 − 导航到测试，然后在右侧选择单元测试项目。命名为DemoTest，然后单击确定。
步骤 8 − 在您的Demo Test 项目中，您需要添加对 Simple 项目和必要的测试程序集的引用。右键单击该项目并选择菜单选项添加引用。
步骤 9 − 在出现的下一个屏幕中，转到“项目”，选择Simple 引用，然后单击“确定”。
步骤 10 − 再次单击添加引用，转到“程序集”，然后在搜索框中键入Web。然后添加System.Web的引用。
步骤 11 − 在单元测试文件中，添加以下代码。此代码将确保 Tutorial 类具有一个字符串类型的 name 变量。它还将断言 Name 应该等于“持续集成”的值。这将是我们的简单测试用例。
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 中，选择菜单选项测试 → 运行 → 所有测试。
运行测试后，您将在 Visual Studio 的左侧看到测试成功运行。
在 TeamCity 中启用持续测试 – 现在所有测试用例都已就位，是时候将它们集成到我们的 Team City 服务器中了。
步骤 13 − 为此，我们需要在项目配置中创建一个构建步骤。转到您的项目主页并单击“编辑配置设置”。
步骤 14 − 然后转到“构建步骤”→“MS Build”，然后单击“添加构建步骤”，如下图所示。
在出现的下一个屏幕中，添加以下值：
将运行程序类型选择为 Visual Studio Tests。
输入可选的测试步骤名称。
将测试引擎类型选择为VSTest。
将测试引擎版本选择为VSTest2013。
在测试文件名称中，提供位置为DemoTest\bin\Debug\DemoTest.dll – 请记住，DemoTest 是包含单元测试的项目的名称。DemoTest.dll 将由我们的第一个构建步骤生成。
单击“保存”，它位于屏幕的末尾。
现在您的项目将有两个构建步骤。第一个是构建步骤，它将构建您的应用程序代码和测试项目。下一个将用于运行您的测试用例。
步骤 15 − 现在是时候将所有代码检入 Git 了，以便可以触发整个构建过程。唯一的区别是这次您需要从Demo 父文件夹运行git add 和git commit 命令，如下图所示。
现在，当构建被触发时，您将看到一个初始输出，该输出将表明测试已通过。
步骤 16 − 如果单击“测试通过”结果并转到“测试”选项卡，您现在将看到 UnitTest1 已执行并且已通过。
持续集成 - 代码检查
持续代码检查是在实际测试运行之前对您的代码进行自动代码审查或检查的过程。检查和测试软件之间存在细微差别。测试是动态的，它执行软件以测试其功能。检查根据一组预定义规则分析代码。
检查器（或静态和动态分析工具）由团队应遵守的已识别标准（通常是编码或设计指标）指导。检查目标的示例包括编码“语法”标准、架构分层遵守、代码重复以及许多其他方面。
持续代码检查缩短了发现问题和修复问题之间的时间。有许多持续代码检查工具可用。在此示例中，我们将使用NCover 3.x，它与 TeamCity 集成。让我们看看如何进行持续代码检查以及它能为我们做什么。
下载并安装 NCover
NCover 是一个单独的产品，需要下载和安装。要下载 NCover，请单击以下链接并下载 32 位安装程序：http://www.ncover.com/info/download.
运行下载的安装程序，然后在安装程序启动后单击“下一步”。
接受许可协议，然后单击“下一步”。
接受默认组件并单击“下一步”。
单击“安装”按钮开始安装。
单击“完成”按钮完成安装。
通过转到C:\Program Files (x86)\NCover\ NCover.Explorer.exe 来首次启动 NCover 安装。您只需要首次安装试用密钥，这是一个简单的过程。
配置 TeamCity 中的项目以使用 NCover
步骤 1 − 转到您的项目主屏幕并单击“编辑配置设置”。
步骤 2 − 转到“构建步骤”并单击TestStep 的“编辑”。持续代码检查需要与已定义的单元测试一起运行。
步骤 3 − 在“.Net 代码覆盖率”部分中，单击“.Net 代码覆盖率工具”。然后选择以下设置：
- 将 .Net 代码覆盖率工具选择为 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 − 现在右键单击该表并选择菜单选项将表脚本化到 → 删除和创建到 → 文件。
步骤 7 − 将文件保存到 demo 项目文件夹中，命名为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 − 在Demo 项目中的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 中添加一个步骤，该步骤将调用数据库脚本。转到您的项目仪表板并单击编辑配置设置。
步骤 12 − 转到“构建步骤”并单击添加构建步骤。
选择以下选项（请注意，MS SQL Server 客户端应安装在 CI 服务器上）。
运行程序类型应为命令行。
给出一个可选的步骤名称。
运行应为带有参数的可执行文件。
命令可执行文件应为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 − 在出现的下一个屏幕中，单击“DB 实例”。
步骤 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 Information Services 来打开它。
步骤 11 − 单击“应用程序池”，您将看到一个名为DefaultAppPool的池。下一步需要它访问 SQL Server。
步骤 12 − 如果我们需要将 ASP.Net 应用程序连接到 MS SQL Server 应用程序，则必须向默认应用程序池授予对 SQL Server 实例的访问权限，以便它可以连接到我们的Demodb数据库。
步骤 13 − 打开 SQL Server Management Studio。转到“登录名”，右键单击并选择菜单选项新建登录名。
在下一个屏幕中，更新以下参数并单击“确定”。
- 登录名：IIS APPPOOL\DefaultAppPool。
- 默认数据库 – 这应该是我们的数据库，即 demodb。
步骤 14 − 创建发布配置文件。发布配置文件用于在 Visual Studio 中创建部署包，然后可以使用 MS Build 和任何 CI 服务器相应地使用它。为此，在 Visual Studio 中，右键单击项目并单击菜单选项“发布”。
步骤 15 − 在出现的下一个屏幕中，选择创建新的发布配置文件，为其命名 – DemoDeployment。然后单击“下一步”按钮。
在随后出现的屏幕中，添加以下值：
- 选择 Web Deploy 作为发布方法。
- 将服务器输入为 localhost。
- 将站点名称输入为 Default Web Site/Demo。
- 将目标 URL 设置为https:///Demo
然后单击“下一步”按钮。
步骤 16 − 在下一个屏幕中，单击“下一步”。
步骤 17 − 在出现的最后一个屏幕中，单击“发布”按钮。
现在，如果您转到项目的C:\Demo\Simple\Properties\PublishProfiles位置，您将看到一个新创建的发布配置文件 xml 文件。此发布配置文件将包含将应用程序发布到本地 IIS 服务器所需的所有详细信息。
步骤 18 − 现在让我们自定义我们的 MSBuild 命令并使用上述发布配置文件，看看会发生什么。在我们的 MSBuild 命令中，我们指定以下参数：
Deploy on Build 为 true – 这将在成功构建后触发自动部署。
然后我们提到使用上面步骤中使用的发布配置文件。
仅需向 MSBuild 部署功能提及正在使用的 Visual Studio 版本。
运行上述命令后，MSBuild 将触发构建和部署过程。您会注意到，它正在将其部署到 IIS 服务器中的默认网站。
现在，如果我们浏览到站点 – https:///Demo/Demo.aspx，我们将看到以下输出，这意味着 MSBuild 成功地将应用程序部署到我们的网站。
步骤 19 − 通过 TeamCity 自动化 – 现在是时候向我们的 TeamCity 服务器添加一项任务，以便根据上述步骤自动使用 MSBuild 部署我们的应用程序。
步骤 20 − 转到您的项目仪表板并单击编辑配置设置。
步骤 21 − 转到“构建步骤”并单击“添加构建步骤”。
选择以下选项：
运行程序类型应为 MSBuild
输入可选步骤名称
将构建路径输入为 Simple/Simple.csproj
将 MSBuild 版本保留为 Microsoft Build Tools 2013
将 MSBuild Toolsversion 保留为 12.0
将命令行设置为 /p:DeployOnBuild = true /p:PublishProfile = DemoDeployement /p:VisualStudioVersion = 12.0
步骤 22 − 单击“保存”。
确保在构建步骤中，部署步骤是链中的最后一步。
步骤 23 − 现在让我们执行最终的git commit，以确保所有文件都在 Git 中，并且可以被 TeamCity 使用。
恭喜，您已成功为您的应用程序设置了完整的持续集成周期，可以在任何时间点运行。
持续集成 - 最佳实践
让我们根据到目前为止我们学到的所有课程，最后回顾一下持续集成的最佳实践：
维护代码库 − 这是最基本的步骤。在我们所有的示例中，从代码库到发布配置文件，再到数据库脚本，所有内容都保存在 Git 存储库中。必须始终确保所有内容都保存在代码存储库中。
自动化构建 − 我们已经了解了如何使用 MSBuild 自动化构建以及使用发布配置文件。这同样是持续集成过程中的一个关键步骤。
使构建自测试 − 确保您可以通过适当的单元测试用例来测试构建，并且这些测试用例应该能够由持续集成服务器运行。
每个人每天都提交到基线 − 这是持续集成的一个关键原则。等到整个过程结束再查看谁破坏了构建是没有意义的。
每次提交（到基线）都应构建 − 对应用程序的每次提交都需要成功构建。如果构建由于任何原因失败，则需要更改代码以确保构建通过。
保持构建速度 − 如果构建速度很慢，则表明整个持续集成过程中存在问题。确保构建始终限制在一定时间内，最好不要超过 10 分钟。
每个人都可以看到最新构建的结果 − TeamCity 仪表板使每个人都能查看所有已通过或失败的构建。这为参与持续集成过程的所有人员提供了良好的洞察力。