在工作流中通过不同阶段自动运行的管道将及早发现问题并帮助您的团队以最有效的方式进行协作。
在本章中，我们将遵循持续集成实践，在每次更改时自动运行管道，以确保我们所有的代码都遵循高质量标准，并且运行并通过所有测试。我们还将准备一个容器以投入生产。
我们将了解如何利用 GitHub 和 Travis CI 等工具以最少的干预创建图像。
在本章中，我们将讨论以下主题：
在本章结束时，您将了解如何在每次代码更改时自动运行测试，以及如何创建一个安全网，使您能够更快、更高效地进行开发。
您需要一个 GitHub 帐户，并且需要是您为持续集成而设置的项目的所有者。作为本章的一部分，我们将创建一个 Travis CI 帐户。
您可以在 GitHub (https://github.com/PacktPublishing/Hands-On-Docker-for-Microservices-with-Python/tree/master /Chapter04)。以 .travis.yml 结尾的文件位于根目录（https://github.com/PacktPublishing/Hands-On-Docker-for-Microservices-with-Python/blob/master/.travis.yml)。
持续集成（通常缩写为CI）是一系列确保代码始终处于工作状态的软件工程实践。
术语持续集成来自历史上必须频繁集成软件，通常每天多次集成。这是因为开发人员使用的本地代码不一定会自动与其他人的代码结合在一起。如今，使用 Git 等源代码控制版本控制软件可以自动使用某些元素。
持续集成强调始终拥有潜在可发布的代码。这使得发布可能非常频繁，代码增量很小。
在将所有流程和基础设施设置到位后，每天多次实施发布是很有可能的（假设代码生成速度足够快）。到达那里可能需要一段时间，但请务必花时间了解该过程并制作所有必要的工具，以确保您在不牺牲稳定性的情况下获得速度。而且，相信我，这是完全可以实现的！
CI 的核心元素是生成与源代码控制系统集成的自动化构建。 软件构建是（从源代码开始）执行一系列操作并产生输出的过程。如果项目是用编译语言编写的，则输出通常是编译后的程序。
如果我们想要拥有高质量的软件，那么构建的一部分涉及检查生成的代码是否符合代码标准。如果代码不遵循这些标准，则构建将返回错误。
可以作为构建的一部分的一些步骤示例如下：
任何可以自动运行的东西都可以成为构建的一部分。可以随时生成本地构建，即使代码仍在进行中。这对于调试和解决问题很重要。但是自动构建将针对每个单独的提交运行，而不是在任何中间阶段。这使得检查哪些代码预计在生产中运行以及哪些代码仍在进行中变得非常明确。
为每个提交运行构建非常快速检测问题。如果提交很小，则很容易确定重大更改。它还可以轻松恢复破坏构建的更改并返回到已知的工作代码。
构建的主要传统问题之一是拥有足够的构建环境，其中包含运行完整构建所需的所有依赖项。这可能包括诸如编译器、运行测试的测试框架、任何静态分析工具和包管理器之类的东西。版本的差异也可能产生错误。
正如我们之前所见，Docker 是封装我们软件的绝佳方式。它允许我们创建一个包含我们的代码和所有能够完成所有步骤的工具的图像。
在上一章中，我们看到了如何基于构建映像在单个命令中运行单元测试。映像本身可以运行自己的单元测试。这将测试环境抽象化并明确定义它。这里唯一需要的依赖是安装 Docker。
请记住，单个构建可以生成多个图像并使它们协同工作。我们在上一章中看到了如何运行单元测试——通过生成服务镜像和数据库镜像——但是还有更多可能的用法。例如，您可以检查在两个不同操作系统上运行的测试，从每个操作系统或不同的 Python 解释器版本创建两个图像，并检查测试是否通过所有这些。
使用 Docker 镜像可以在所有环境中实现标准化。我们可以使用我们在自动化环境中执行的相同命令，在开发环境中本地运行映像。这简化了错误和问题的查找，因为它在构建运行的任何地方创建了相同的环境，包括一个封装的操作系统。
请注意，我们不一定需要创建运行整个构建的单个步骤；它可能是几个 Docker 命令，甚至使用不同的图像。但要求是它们都包含在 Docker 中，这是运行它所需的唯一软件。
使用 Docker 构建的主要产品是 Docker 镜像或镜像。我们需要正确标记它们，但前提是构建成功。
CI 工具有助于阐明构建应如何进行并围绕管道的概念工作。管道是阶段的集合。如果其中任何一个不成功，则管道将停止。
管道中的每个阶段都可以生成可以在以后的阶段使用的元素，或者可以作为完整构建的最终产品使用。这些最终元素被称为工件。
我们来看一个管道的例子：
第一阶段从源代码控制系统中提取最新提交。然后，我们构建所有容器并运行测试和静态分析。如果一切顺利，我们标记生成的 server 容器并将其推送到注册表。
CI 工具通常允许在管道中进行很好的配置，包括并行运行不同阶段的可能性。为了能够并行运行阶段，它们需要能够并行化，这意味着它们不应更改相同的元素。
如果选择的 CI 工具允许并行运行阶段，则管道可以定义如下：
请注意，我们并行构建数据库和测试图像。下一阶段构建其余元素，这些元素已经在缓存中可用，因此它会非常快。测试和静态分析都可以在两个不同的容器中并行运行。
这可能会加速复杂的构建。
该管道在特定于 Travis CI 工具的脚本中进行了描述。稍后我们将看一个使用 Travis CI 的示例。
我们什么时候运行构建？每次推送一个提交。但每一个结果都不一样。在处理诸如 Git 之类的源代码控制系统时，我们通常有两种分支：
它们实现了特定的功能或错误修复，准备就绪后将合并到主分支中，如下图所示：
在这个例子中，我们看到了主分支（master）是如何被分支来开发feature A的。 Feature A 之后简单介绍。有一个 功能 B 尚未合并，因为它还没有准备好。有了关于哪些构建成功与否的额外信息，我们可以知道何时将功能分支合并到主分支是安全的：
尚未合并的功能分支中的破坏不是很大，但是在它正在进行中时，预计会发生。同时，主分支的破损是应该尽快修复的事件。如果主分支状态良好，则意味着它有可能被释放。
GitHub 有一个模型：拉取请求。我们将配置拉取请求以自动检查构建是否已通过并避免合并。如果我们在合并回来之前强制任何功能分支也与主分支保持同步，那么主分支最终会非常稳定。
在主分支中拥有不间断的成功构建线也非常有助于培养项目的稳定性和质量感。如果主分支损坏非常罕见，那么使用最新主分支创建新版本的信心非常高。
Travis CI (https://travis-ci.com/) 是一种流行的持续集成服务，可免费用于公共 GitHub 项目。与 GitHub 的集成非常简单，它允许您配置它运行的平台，例如 macOS、Linux 甚至 iOS。
Travis CI 与 GitHub 紧密集成，因此您只需登录 GitHub 即可访问它。我们将看到如何将我们的项目连接到它。
Travis 与其他 CI 工具的工作方式略有不同，它通过启动新 VM 来创建独立作业。这意味着为前一阶段创建的任何工件都需要复制到其他地方，以便在下一阶段开始时下载。
这有时会让事情变得有点不切实际，一个简单的解决方案是为每个单独的工作构建多次。
要配置 Travis CI，我们首先从 GitHub 添加一个存储库。
要将 repo 添加到 Travis CI，我们需要执行以下步骤：
您需要拥有 GitHub 存储库的所有者权限，然后您就可以开始了！
Travis CI 的主要元素是创建 .travis.yml 文件。
.travis.yml 描述了构建及其不同的步骤。构建在一个或多个 VM 中执行。可以通过指定通用操作系统和特定版本来配置这些 VM。默认情况下，它们在 Ubuntu Linux 14.04 Trusty 中运行。您可以在此处找到有关可用操作系统的更多信息：https://docs.travis-ci .com/user/reference/overview/。
使用 Docker 可以让我们抽象出大部分操作系统的差异，但我们需要确保我们使用的具体 docker 和 docker-compose 版本是正确的。
我们将使用以下代码启动 .travis.yml，确保存在有效的 docker-compose 版本 (1.23.2)：
before_install 块将在我们所有的虚拟机中执行。现在，为了运行测试，我们添加一个 script 块：
我们构建所有要使用的图像，然后运行测试。请注意，使用 PostgreSQL 数据库运行测试需要您构建 db 容器。
这将运行所有测试。推入 repo 后，我们可以看到构建在 Travis CI 中开始：
一旦完成，我们可以通过它被标记为绿色来判断构建成功。然后可以检查日志以获取更多信息：
现在您可以在日志末尾看到测试：
这对于检测问题和构建中断很有用。现在，让我们看看工作在 Travis 中是如何工作的。
Travis 将整个构建划分为一系列阶段，这些阶段将一个接一个地运行。在每个阶段，可以有多个工作。同一构建中的所有作业都将并行运行。
正如我们之前所见，我们可以将测试和静态分析配置为并行运行，方法是将 script 部分替换为 工作 部分：
这在一个阶段隐含地创建了两个工作。该阶段名为 tests，作业名为 "Unit Tests" 和 "Static Analysis"。
结果出现在 Travis 页面上：
请注意，在这两种情况下，由于作业是独立的，因此它们需要构建所需的图像。由于单元测试作业需要构建 db 映像，这需要几分钟，它比静态分析要慢。
您可以查看每个作业的详细日志。请注意环境设置和 before_install 操作如何在所有作业中执行。
这种划分可以不仅可以相当显着地加快构建速度，还可以明确问题所在。一眼看去，你可以看到破坏因素要么是单元测试，要么是静态分析。这消除了混乱。
默认情况下，Travis CI 将发送电子邮件通知构建结果，但仅在 构建被破坏或修复了破坏的构建时。 这避免了不断发送成功 电子邮件并仅在需要采取行动时采取行动。默认情况下，电子邮件仅发送给提交者（以及提交作者，如果不同）。
Travis 允许我们配置通知电子邮件并连接更多通知系统，包括 Slack、IRC 甚至 OpsGenie，它们能够根据待命时间表发送 SMS 消息。在此处查看完整文档以获取更多信息：https://docs.travis-ci.com/user /通知/。
为了充分利用我们配置的 CI 系统，我们需要确保在将构建合并到主分支之前检查它。为此，我们可以将 master in GitHub 配置为主分支，并在合并之前添加需求：
Details 链接将您带到 Travis CI 和特定构建。您还可以查看构建的历史记录：
构建完成后，GitHub 不会让您合并拉取请求：
详细信息可以在 Travis CI 的构建页面上找到：
修复问题并推送代码将触发另一个构建。这次就成功了，拉取请求合并成功。您可以查看每个提交如何拥有自己的构建信息，无论它是正确的还是不正确的：
我们现在可以合并到 master 分支，确信 master 分支在运行测试时不会中断。
构建结果也可以在 GitHub 的 Commits 视图中查看。
在我们的构建创建了一个 Docker 镜像之后，我们需要能够与团队的其他成员共享它或部署它。如前一章所述，我们将使用 Docker Hub 中的 Docker 注册表来推送镜像。
让我们从设置秘密变量开始。
为了能够推送到 Docker 仓库，我们首先需要配置一个密码来登录 Docker 注册表。这需要通过 Travis CI 中的 secrets 配置来完成，以避免在 GitHub 存储库中提交敏感信息：
此操作创建两个环境变量，在构建期间可用。别担心——它们不会显示在日志中：
我们现在可以在 before_install 部分添加正确的登录命令，以便 Docker 服务可以连接和推送图像：
下一阶段是构建和标记生成的图像。
以下代码将添加一个新阶段，该阶段将构建、标记并最终将结果推送到 Docker 注册表：
第一部分为服务器构建最终映像并使用分支名称对其进行标记。为了部署它，我们将添加一个 deploy 部分：
当分支为 master 时，deploy 部分将执行 script 命令。现在，我们的构建还将生成最终图像并推送它。这将确保我们的注册表在我们的主分支中获得最新版本。
我们可以添加更多的 deploy 条件来推送标签；例如，如果我们创建一个新的 Git 标签，我们可以使用适当的标签推送结果图像。
我们可以将标签添加到 deploy 部分：
您可以在此处查看完整的部署文档：https://docs.travis-ci.com/user/部署。我们已经介绍了 script 提供程序，这是一种创建我们自己的命令的方式，但它提供对 Heroku、PyPI（在创建 Python 包的情况下）和 AWS S3 等提供程序的支持。
可以将每个构建的映像推送到由其 Git SHA 标识的注册表。当进行中的工作可以共享用于演示目的、测试等时，这会很有用。
为此，我们需要在 before_install 部分中使用 Git SHA 创建一个环境变量：
push 部分然后添加图像的标签和推送：
由于此操作发生在 deploy 部分之前，因此它将在到达此部分的每个构建上生成。
请注意，注册表需要根据您自己的注册表详细信息进行调整。如果您克隆示例存储库，则需要更改后者。
在本章中，我们介绍了持续集成实践并探讨了 Docker 如何帮助实现它们。我们还研究了如何设计一个管道，以确保我们的代码始终遵循高标准并尽快检测到偏差。在 GitHub 中使用 Git 分支和拉取请求也随之而来，因为我们可以确定何时可以将代码合并到主分支中并进行部署。
然后我们介绍了 Travis CI 作为与 GitHub 一起使用以实现持续集成的好工具，并讨论了它的特性。我们学习了如何在 Travis CI 中创建管道，从创建 .travis.yml 文件，如何配置作业，如何使构建推送经过验证的 Docker 镜像到我们的 Docker 注册表，以及如何被通知。
我们描述了如何加速并行运行部分，以及如何将值设置为机密。我们还配置了 GitHub，以确保 Travis CI 管道在将新代码合并到我们的主分支之前成功运行。
在下一章中，我们将学习基本的 Kubernetes 操作和概念。
要了解有关持续集成和其他工具的更多信息，您可以查看持续集成和交付实践一书（https://www.packtpub.com/eu/virtualization-and-cloud/hands-continuous-integration-and-delivery ），它不仅涵盖 Travis CI，还涵盖其他工具，例如 Jenkins 和 CircleCI。如果您想深入了解 GitHub 及其所有可能性，包括如何有效协作以及它支持的不同工作流程，请在 GitHub Essentials (https://www.packtpub.com/eu/web-development/github-essentials-second-edition)。