本文翻译自国外论坛 medium，原文地址：本文翻译自国外论坛 medium，原文地址：https://medium.com/gitconnected/basics-of-ci-cd-a98340c60b04
任何软件项目的主要目标都是通过业务流程快速更新迭代来赚钱。我们越快向客户发布新版本，对我们的公司就约有好处。但如何快速实现版本更新迭代呢？我们可以手动完成。例如可以通过 SSH 连接到远程服务器。然后我们可以使用新代码克隆代码库、构建它并使用命令行运行它。尽管这个方式确实有效，但这并不是一种便捷的方法。
因此本篇文章我们将讨论如何将产品发布和开发过程实现自动化。
本文标题所写的 CI 和 CD 是两个缩写，分别代表持续集成和持续交付。
CI：持续集成描述了代码库变更的过程。让我们看一个简单的模式，它给出了团队开发的示例。
一群人可以同时工作。但所有更改最终都会转移到 master 分支。不管怎样，即使是这样一个简单的模型也会引发一些问题。
软件开发中，通常会将 master 分支作为主分支。dev 作为本地开发分支。
为了完成以上几点，我们可以把所有描述的要求都进行手动验证。不过这种方法非常复杂，当代码库越来越庞大时，这个方式并不可取。
于是乎 CI 的出现是为了完成以上所提出的几点建议并将其自动化。
第一点，我们如何知道进入 master 分支的代码可以编译通过？
我们需要在架构中添加另一个模块，如下图。
大多数 CI 流程都可以根据这个架构来描述。
bugfix/wrong-sorting 分支），并与主分支合并。./gradlew 脚本执行构建操作。该过程保证进入主分支的任何代码都不会破坏进一步的构建。
第二点，我们希望开发人员为代码编写测试。我们如何验证测试覆盖率没有下降？
让我们把任务变得更复杂。假设我们要设置最小测试覆盖率。任何时刻 master 分支的测试覆盖率都不应低于 50%。 Jacoco 插件可以轻松解决这个问题。如果测试覆盖率值小于可接受的值，我们只需在构建时返回失败进行配置即可。
JaCoCo 是一个免费的 Java 代码覆盖库，由 EclEmma 团队根据多年来使用和集成现有库的经验教训创建。
JaCoCo 地址：https://www.eclemma.org/jacoco
Jacoco 的使用非常简单，只需要在项目启动后配置插件就能工作。
想象一下，我们正在开发一款已有五年历史的产品。自第一次提交以来，一直没有测试覆盖率检查。开发人员随意添加测试，没有任何纪律。但有一天，我们决定提高测试覆盖率。我们调整 Jacoco 插件，将最小测试覆盖率提高到 60%。一段时间后，开发人员打开一个新的 Pull 请求。然后他们突然意识到整个项目测试覆盖率只有 30%。因此要成功完成任务，整个项目必须覆盖至少 60% 的代码。正如我们可能猜到的，对于这个已有五年历史的项目来说，这几乎是一个无法解决的问题。
如果我们只验证新的代码更改而不验证整个产品的老代码怎么办？如果开发人员在 Pull Request 中更改了 200 行代码，他们需要测试覆盖至少 120 行代码（如果测试覆盖率等于 60%）。我们如何将只验证新代码的测试覆盖率应用到项目中呢？有一个解决方案是 SonarCloud。
SonarCloud 是一个云服务化的代码审查工具，能让团队一致、高效地交付干净的代码，该工具可轻松集成到云 DevOps 平台并扩展 CI/CD 工作流程。
SonarCloud 地址：https://www.sonarsource.com/products/sonarcloud/
Jacoco 报告被发送到 SonarCloud 服务器。
SonarCloud 服务器保存先前老项目代码计算的统计数据，再计算新代码的统计数据。然后分析结果被发送到 CI 服务器，CI 服务器将其发送回 Git 服务器。
应用了 SonarCloud 的工作流程能提供在任何产品演化阶段应用强制测试文化的机会，非常方便易于集成。
第三点，所有团队成员都应使用指定的代码风格来格式化代码。我们如何检查可能存在的违规行为？
说到代码风格，没有太多区别。我们可以尝试 Checkstyle 插件。它会自动使违反任何规定要求的构建失败。例如代码中可能有未使用的导入语句。此外我们还可以查看运行代码分析并将结果显示为一堆图表。
Checkstyle 是一种开发工具，可帮助程序员编写符合编码标准的 Java 代码。它自动化了检查 Java 代码的过程，从而使人们摆脱了这项无聊（但重要）的任务。这使其成为想要强制执行编码标准的项目的理想选择。
Checkstyle 地址：https://checkstyle.sourceforge.io/
CD：持续交付描述了新产品版本自动部署的过程。
让我们对 CI 模式进行一些更改。如下就是真实项目中 CI/CD 流程的样子。
首先 CI 服务器现在被命名为 CI/CD 服务器 CI 和 CD 作业经常是使用同一个任务组件（例如 Jenkins）执行。
虽然这不是规则。例如可以将 CI 工作委托给 GitLab CI，将 CD 工作委托给 Jenkins。
架构的右侧部分代表 CI，我们之前已经讨论过。左侧部分代表 CD，CD 作业构建项目（或重用 CI 阶段生成的制品）并将其部署到终端服务器。
值得一提的是，在如上例子中，终端服务器是一个抽象。例如部署可能会发布到 Kubernetes 集群。因此可能有多个服务器。
部署阶段完成后，通常会发送电子邮件。例如 CD 服务器可以通知订阅者部署成功或失败。
有一个重要的问题。我们什么时候应该运行 CD 作业？触发因素可能会有所不同。
第一点设置流程，以便 CI 和 CD 作业始终按顺序运行。这种方法在开源项目开发中相当流行。语义发布库有助于调整项目以透明地集成此过程。
第二点与 CI 流程无关。因为项目是根据一些预定义的时间表部署的。例如每天凌晨 01:00。
第三点与第一点类似。虽然有差异。假设我们的代码库中有两个主要分支。开发分支和主分支。开发分支包含最新的更改。而主分支只有线上稳定代码。如果我们只需要部署 master 分支，则不需要在合并到 develop 分支时触发 CD 作业。
最后一点是所有方法的汇总。例如开发分支可能会根据计划部署到开发环境。主分支会在每次拉取请求合并时部署到生产环境。
现如今，业界提供了数十种自动化 CI/CD 流程的解决方案。让我们看一下其中的一些。
这就是我想说的有关 CI/CD 流程基础知识的全部内容。如果我们有任何疑问或建议，请在下方留下我们的评论。谢谢阅读！
关注公众号【waynblog】每周分享技术干货、开源项目、实战经验、国外优质文章翻译等，您的关注将是我的更新动力！