本文翻译自国外论坛 medium，原文地址：本文翻译自国外论坛 medium，原文地址：medium.com/gitconnecte…, 原文作者：Semyon Kirekov

任何软件项目的主要目标都是通过业务流程快速更新迭代来赚钱。我们越快向客户发布新版本，对我们的公司就约有好处。但如何快速实现版本更新迭代呢？我们可以手动完成。例如可以通过 SSH 连接到远程服务器。然后我们可以使用新代码克隆代码库、构建它并使用命令行运行它。尽管这个方式确实有效，但这并不是一种便捷的方法。

因此本篇文章我们将讨论如何将产品发布和开发过程实现自动化。

CI

CI：持续集成描述了代码库变更的过程。让我们看一个简单的模式，它给出了团队开发的示例。

一群人可以同时工作。但所有更改最终都会转移到 master 分支。不管怎样，即使是这样一个简单的模型也会引发一些问题。

1. 我们如何知道进入 master 分支的代码可以编译通过？
2. 我们希望开发人员为代码编写测试。我们如何验证测试覆盖率没有下降？
3. 所有团队成员都应使用指定的代码风格来格式化代码。我们如何检查可能存在的违规行为？

为了完成以上几点，我们可以把所有描述的要求都进行手动验证。不过这种方法非常复杂，当代码库越来越庞大时，这个方式并不可取。

于是乎 CI 的出现是为了完成以上所提出的几点建议并将其自动化。

第一点，我们如何知道进入 master 分支的代码可以编译通过？

我们需要在架构中添加另一个模块，如下图。

大多数 CI 流程都可以根据这个架构来描述。

1. 每次打开 Pull 请求（以及推送新更改）时，Git 服务器都会向 CI 服务器发送一条通知。
2. CI 服务器克隆代码库，检出错误分支（例如bugfix/wrong-sorting分支），并与主分支合并。
3. 然后构建脚本将被启动。例如./gradlew脚本执行构建操作。
4. 如果上一步脚本命令返回 0 代码，则构建成功。否则视为失败。
5. CI 服务器将带有构建结果的请求发送到 Git 服务器。
6. 如果构建成功，则允许合并 Pull 请求。否则合并将被阻止。

该过程保证进入主分支的任何代码都不会破坏进一步的构建。

第二点，我们希望开发人员为代码编写测试。我们如何验证测试覆盖率没有下降？

让我们把任务变得更复杂。假设我们要设置最小测试覆盖率。任何时刻 master 分支的测试覆盖率都不应低于 50%。 Jacoco 插件可以轻松解决这个问题。如果测试覆盖率值小于可接受的值，我们只需在构建时返回失败进行配置即可。

Jacoco 的使用非常简单，只需要在项目启动后配置插件就能工作。

想象一下，我们正在开发一款已有五年历史的产品。自第一次提交以来，一直没有测试覆盖率检查。开发人员随意添加测试，没有任何纪律。但有一天，我们决定提高测试覆盖率。我们调整 Jacoco 插件，将最小测试覆盖率提高到 60%。一段时间后，开发人员打开一个新的 Pull 请求。然后他们突然意识到整个项目测试覆盖率只有 30%。因此要成功完成任务，整个项目必须覆盖至少 60% 的代码。正如我们可能猜到的，对于这个已有五年历史的项目来说，这几乎是一个无法解决的问题。

如果我们只验证新的代码更改而不验证整个产品的老代码怎么办？如果开发人员在 Pull Request 中更改了 200 行代码，他们需要测试覆盖至少 120 行代码（如果测试覆盖率等于 60%）。我们如何将只验证新代码的测试覆盖率应用到项目中呢？有一个解决方案是 SonarCloud。

Jacoco 报告被发送到 SonarCloud 服务器。

SonarCloud 服务器保存先前老项目代码计算的统计数据，再计算新代码的统计数据。然后分析结果被发送到 CI 服务器，CI 服务器将其发送回 Git 服务器。

应用了 SonarCloud 的工作流程能提供在任何产品演化阶段应用强制测试文化的机会，非常方便易于集成。

第三点，所有团队成员都应使用指定的代码风格来格式化代码。我们如何检查可能存在的违规行为？

说到代码风格，没有太多区别。我们可以尝试 Checkstyle 插件。它会自动使违反任何规定要求的构建失败。例如代码中可能有未使用的导入语句。此外我们还可以查看运行代码分析并将结果显示为一堆图表。

CD

CD：持续交付描述了新产品版本自动部署的过程。

让我们对 CI 模式进行一些更改。如下就是真实项目中 CI/CD 流程的样子。

首先 CI 服务器现在被命名为 CI/CD 服务器 CI 和 CD 作业经常是使用同一个任务组件（例如 Jenkins）执行。

架构的右侧部分代表 CI，我们之前已经讨论过。左侧部分代表 CD，CD 作业构建项目（或重用 CI 阶段生成的制品）并将其部署到终端服务器。

部署阶段完成后，通常会发送电子邮件。例如 CD 服务器可以通知订阅者部署成功或失败。

有一个重要的问题。我们什么时候应该运行 CD 作业？触发因素可能会有所不同。

1. 每次合并请求后进行部署。
2. 按计划部署。
3. 在每个拉取请求合并到特定分支后进行部署。
4. 将以上选项进行组合。

第一点设置流程，以便 CI 和 CD 作业始终按顺序运行。这种方法在开源项目开发中相当流行。语义发布库有助于调整项目以透明地集成此过程。

第二点与 CI 流程无关。因为项目是根据一些预定义的时间表部署的。例如每天凌晨 01:00。

第三点与第一点类似。虽然有差异。假设我们的代码库中有两个主要分支。开发分支和主分支。开发分支包含最新的更改。而主分支只有线上稳定代码。如果我们只需要部署 master 分支，则不需要在合并到 develop 分支时触发 CD 作业。

最后一点是所有方法的汇总。例如开发分支可能会根据计划部署到开发环境。主分支会在每次拉取请求合并时部署到生产环境。

工具

现如今，业界提供了数十种自动化 CI/CD 流程的解决方案。让我们看一下其中的一些。

1. Jenkins。世界上最受欢迎的 CI/CD 工具之一。由于其开源政策，它变得非常受欢迎。我们无需支付任何费用。Jenkins 允许使用 Groovy 强制描述构建管道。一方面，它提供了更多的灵活性。但另一方面，它也需要更高的能力水平。
2. GitHub Actions。 CI/CD 工具包含在 GitHub 和 GitHub Enterprise 中。与 Jenkins 不同，GitHub Actions 提供带有 YAML 配置的声明式构建。此外，该解决方案与不同的质量保证系统（例如 SonarCube）进行了大量集成。因此，构建只需几行文本即可描述。
3. GitLab CI。它与 GitHub Actions 非常相似。尽管如此，它还是有其特殊之处。例如 GitLab CI 可以指出构建失败的特定测试。
4. Travis CI。云 CI/CD 服务。它提供了许多不需要复杂配置的功能。例如对应该隐藏在公共代码库中的数据进行加密。此外一个不错的好处是 Travis CI 可以完全免费地应用于 GitHub、GitLab 和 BitBucket 中的开源项目。

结论

这就是我想说的有关 CI/CD 流程基础知识的全部内容。如果我们有任何疑问或建议，请在下方留下我们的评论。谢谢阅读！