持续集成 - 快速指南

持续集成 - 概述

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

为什么持续集成？

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

所有软件组件是否都按其应有的方式协同工作？– 有时系统可能变得非常复杂，每个组件都有多个接口。在这种情况下，确保所有软件组件彼此无缝协作始终至关重要。
代码对于集成来说是否太复杂？– 如果持续集成过程持续失败，则可能是代码过于复杂。这可能是一个信号，要求应用适当的设计模式来降低代码的复杂性并提高可维护性。
代码是否符合既定的编码标准？– 大多数测试用例将始终检查代码是否遵循正确的编码标准。通过在自动化构建之后进行自动化测试，可以很好地检查代码是否满足所有所需的编码标准。
自动化测试覆盖了多少代码？– 如果测试用例没有涵盖代码所需的功能，那么测试代码就没有意义。因此，确保编写的测试用例涵盖应用程序的所有关键场景始终是一个很好的做法。
最新更改后所有测试都成功了吗？– 如果测试失败，则没有必要继续部署代码，因此这是检查代码是否已准备好进入部署阶段的好时机。

工作流程

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

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

首先，开发人员将代码提交到版本控制存储库。同时，集成构建机器上的持续集成服务器轮询源代码存储库的变化（例如，每隔几分钟）。
提交发生后不久，持续集成服务器检测到版本控制存储库中发生了更改，因此持续集成服务器从存储库中检索代码的最新副本，然后执行构建脚本，该脚本集成了软件
持续集成服务器通过将构建结果通过电子邮件发送给指定的项目成员来生成反馈。
如果该项目的构建通过，则进行单元测试。如果测试成功，代码就可以部署到登台或生产服务器。
持续集成服务器继续轮询版本控制存储库中的更改，并重复整个过程。

持续集成 - 软件

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

源代码库

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

系统要求

记忆	2 GB 内存（推荐）
磁盘空间	200 MB HDD 用于安装。需要额外的存储空间来存储项目源代码，这取决于所添加的源代码。
操作系统版本	可以安装在 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 - 在以下屏幕中，接受“签出 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 的步骤和系统要求。

系统要求

记忆	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 需要以哪个帐户运行。选择系统帐户并单击下一步。

步骤 9 - 接下来它将询问需要启动的服务。接受默认值，然后单击“下一步”。

配置 TeamCity

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

http://本地主机:8080

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

步骤 2 - 下一步是指定用于存储所有 TeamCity 工件的数据库。出于本教程的目的，可以选择Internal (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>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告诉项目运行所需的.Net 版本。这是绝对必需的，因为如果构建服务器没有这样做，构建将会失败。

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

部署环境 – 亚马逊

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

数据库服务器

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

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

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

步骤 2 - 转到 RDS 部分创建数据库。

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

步骤 4 - 单击出现的下一个屏幕中的启动数据库选项。

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

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

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

步骤 8 - 在出现的下一个屏幕中，接受所有默认设置并单击启动数据库实例。

步骤 9 - 然后您将看到一个屏幕，显示数据库正在成功启动。在同一页面上，将有一个用于查看数据库实例的按钮。单击该链接可查看正在设置的数据库实例。

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

网络服务器

下一步是在 Amazon 上创建 Web 服务器，该服务器将托管 Web 应用程序。这可以通过遵循后续步骤来完成。

步骤 1 - 转到 Amazon 控制台 - https://aws.amazon.com/console/。

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

步骤 2 - 转到EC2 部分创建您的 Web 服务器。

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

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

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

步骤 6 - 接受出现的下一个屏幕上的默认设置，然后选择选项下一步：添加存储。

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

步骤 8 - 接受下一个屏幕上的默认设置，然后选择下一步：配置安全组选项。

步骤 9 - 接受下一个屏幕上的默认设置，然后选择Review and Launch选项。

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

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

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

持续集成 - 降低风险

项目有可能会出现问题。通过有效地实践 CI，您可以了解整个过程中每一步发生的情况，而不是等到项目进入开发周期后才知道。CI 可以帮助您在风险发生时识别并减轻风险，从而更轻松地根据具体证据评估和报告项目的运行状况。

本节将重点讨论通过使用持续集成可以避免的风险。

任何项目都存在许多需要管理的风险。通过在开发生命周期的早期消除风险，当系统实际上线时，这些风险发展成问题的机会就会减少。

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

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

对于我们是否能够构建该软件几乎没有信心。
在内部（即测试团队）或外部（即客户）交付软件之前需要经历漫长的集成阶段，在此期间没有其他任何事情可以做。
无法生成和重现可测试的版本。

解决方案

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

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

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

害怕更改或重构数据库或源代码。
难以用不同的测试数据集填充数据库。
难以维护开发和测试环境（例如，开发、集成、QA 和测试）。

解决方案

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

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

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

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

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

解决方案

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

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

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

风险 3 – 缺乏项目可见性

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

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

解决方案

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

风险 4 – 低质量软件

有缺陷，然后就有潜在的缺陷。当您的软件设计不佳、不符合项目标准或维护复杂时，您可能会存在潜在的缺陷。有时，人们将其称为代码或设计气味——“可能出现问题的症状”。

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

解决方案

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

持续集成-版本控制

版本控制系统，也称为源代码控制、源代码管理系统或修订控制系统，是一种保留文件多个版本的机制，这样当您修改文件时，您仍然可以访问以前的修订版本。

第一个流行的版本控制系统是名为SCCS （源代码控制系统）的专有 UNIX 工具，其历史可以追溯到 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 等工具。
让您的构建进行自测试- 构建应该是可测试的。构建发生后，应立即运行测试用例，以确保可以对软件的各种功能进行测试。
每次提交都应在集成机器上构建- 集成机器是构建服务器，应确保构建在此机器上运行。这意味着所有依赖组件都应该存在于持续集成服务器上。
保持快速构建- 构建应该在几分钟内完成。构建不应花费数小时才能完成，因为这意味着构建步骤未正确配置。
在生产环境的克隆中进行测试- 构建环境本质上应该与生产环境接近。如果这些环境之间存在巨大差异，那么即使构建在构建服务器上传递，也可能会在生产中失败。
每个人都可以看到正在发生的事情- 构建、测试和部署的整个过程应该对所有人可见。
自动化部署- 持续集成导致持续部署。确保构建能够轻松部署到临时或生产环境中是绝对必要的。

持续集成 - 要求

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

定期签入- 持续集成正常工作的最重要实践是频繁签入源代码存储库的主干或主线。代码签入每天至少应该进行几次。定期检查还有很多其他好处。它使更改更小，因此破坏构建的可能性更小。这意味着当任何后续版本中出现错误时，可以恢复到最新的软件版本。

它还有助于更加严格地重构代码并坚持保留Behave的小更改。它有助于确保更改大量文件的更改不太可能与其他人的工作发生冲突。它允许开发人员更具探索性，尝试想法并通过恢复到最后提交的版本来放弃它们。
创建全面的自动化测试套件- 如果您没有全面的自动化测试套件，则通过构建仅意味着可以编译和组装应用程序。虽然对于某些团队来说这是迈出的一大步，但必须进行一定程度的自动化测试，以确保您的应用程序确实正常工作。

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

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

组件测试测试应用程序的多个组件的Behave。与单元测试一样，它们并不总是需要启动整个应用程序。但是，它们可能会攻击数据库、文件系统或其他系统（可能会被删除）。组件测试通常需要更长的时间才能运行。
保持构建和测试过程简短- 如果构建代码和运行单元测试花费的时间太长，您将遇到以下问题。
- 人们将停止进行完整的构建，并在签入之前运行测试。您将开始遇到更多失败的构建。
- 持续集成过程将花费很长时间，以至于在您可以再次运行构建时已经发生了多次提交，因此您不知道哪个签入破坏了构建。
- 人们会减少签入的频率，因为他们必须等待很长时间等待软件构建和测试运行。
不要签入损坏的构建- 持续集成的最大错误是签入损坏的构建。如果构建失败，负责的开发人员正在等待修复它。他们尽快查明破损原因并修复。如果我们采用这种策略，我们将始终处于最佳位置，找出导致破损的原因并立即修复。

如果我们的一位同事进行了签入并因此破坏了构建，那么为了有最好的机会修复它，他们将需要清楚地解决问题。当这条规则被打破时，构建的修复将不可避免地需要更长的时间。人们习惯于看到构建被破坏，很快你就会陷入构建始终被破坏的情况。
提交前始终在本地运行所有提交测试- 始终确保为应用程序设计的测试首先在本地计算机上运行，然后再在 CI 服务器上运行。这是为了确保编写正确的测试用例，并且如果 CI 过程中出现任何失败，那是因为测试结果失败。
对因更改而导致的所有损坏承担责任- 如果您提交更改并且您编写的所有测试都通过了，但其他测试都损坏了，则构建仍然损坏。通常这意味着您在应用程序中引入了回归错误。您有责任修复因更改而未通过的所有测试，因为您进行了更改。在 CI 的背景下，这似乎是显而易见的，但实际上在许多项目中这并不是常见的做法。

持续集成 - 构建解决方案

有多种适用于各种编程语言的构建工具。一些最流行的构建工具包括Ant for Java和MSBuild for .NET。使用专门为构建软件而设计的脚本工具，而不是一组自定义的 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命令执行此操作，如以下屏幕截图所示。这 '。' 表示法用于表示目录和子目录中的所有文件都应包含在提交中。

步骤 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 。