软件开发常说的CI/CD是什么

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

CI

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

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

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

软件开发中，通常会将 master 分支作为主分支。dev 作为本地开发分支。

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

于是乎 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 插件，将最小测试覆盖率提高到 60%。一段时间后，开发人员打开一个新的 Pull 请求。然后他们突然意识到整个项目测试覆盖率只有 30%。因此要成功完成任务，整个项目必须覆盖至少 60% 的代码。正如我们可能猜到的，对于这个已有五年历史的项目来说，这几乎是一个无法解决的问题。

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

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

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

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

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

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

Checkstyle 是一种开发工具，可帮助程序员编写符合编码标准的 Java 代码。它自动化了检查 Java 代码的过程，从而使人们摆脱了这项无聊（但重要）的任务。这使其成为想要强制执行编码标准的项目的理想选择。

Checkstyle 地址：https://checkstyle.sourceforge.io/

CD

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

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

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

虽然这不是规则。例如可以将 CI 工作委托给 GitLab CI，将 CD 工作委托给 Jenkins。

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

值得一提的是，在如上例子中，终端服务器是一个抽象。例如部署可能会发布到 Kubernetes 集群。因此可能有多个服务器。

部署阶段完成后，通常会发送电子邮件。例如 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 流程基础知识的全部内容。谢谢阅读！