CI/CD基础知识

任何软件项目的首要目标都是通过业务流程自动化来盈利。新版本发布速度越快，对公司就越有利。但如何快速实现发布流程呢？当然，你可以手动操作。例如，可以通过 SSH 连接到远程服务器，然后克隆包含新代码的仓库，构建并运行它。虽然这种方法可行，但效率不高。因此，今天我们将探讨产品发布和开发流程本身的自动化。

CI 和 CI 是Continuous Integration和Continuous Delivery的两个缩写。

置信区间

持续集成描述了变更流向代码库的过程。让我们来看一个简单的模式示例，它展示了团队开发的情况。

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

1. 我们如何才能确定发送到该分支的代码能够master编译通过？
2. 我们希望开发人员为代码编写测试。我们如何验证测试覆盖率没有下降？
3. 所有团队成员都应按照指定的代码风格编写代码。我们如何检查可能存在的违规行为？

当然，所有描述的需求都可以手动验证。尽管这种方法相当杂乱无章。更重要的是，随着团队规模的扩大，这种方法会变得越来越难以维持。

引入CI是为了实现上述方案的自动化。

我们先来看第一点。如何确保即将进行的更改不会破坏构建？为此，我们需要在模式中添加另一个代码块。

大多数 CI 过程都可以根据该算法进行描述。

1. 每次打开 Pull Request（以及推送新更改）时，Git 服务器都会向 CI 服务器发送通知。
2. CI 服务器克隆存储库，检出源分支（例如bugfix/wrong-sorting），并与分支合并master。
3. 然后启动构建脚本。例如，./gradlew build。
4. 如果命令返回代码为0，则构建成功；否则，视为构建失败。
5. CI 服务器将构建结果请求发送到 Git 服务器。
6. 如果构建成功，则允许合并拉取请求。否则，合并将被阻止。

该过程保证了任何移至master分支的代码都不会破坏后续的构建。

测试覆盖率检查

让我们把任务复杂化一些。假设我们要设置最低测试覆盖率标准。也就是说，任何时候分支的覆盖率master都不能低于某个阈值50%。Jacoco插件可以轻松解决这个问题。你只需要配置它，使其在测试覆盖率低于设定值时构建失败即可。

这种方法的实现非常简单。但它有一个限制：它仅适用于项目启动时就已配置好的插件。

想象一下，你正在开发一个已经五年的产品。从第一次提交代码开始，就没有进行过任何测试覆盖率检查。开发人员随意添加测试，没有任何规范。但有一天，你决定增加测试数量。你调整了 Jacoco 插件，使最小覆盖率达到 100% 60%。过了一段时间，一位开发人员提交了一个新的 Pull Request。然后他们突然发现测试覆盖率只有 100% 30%。因此，为了成功完成任务，必须覆盖至少 100 30%% 的产品代码。正如你可能已经猜到的，对于一个已经运行五年的项目来说，这几乎是一个无法解决的问题。

如果我们只验证即将发生的代码变更，而不是整个产品呢？如果开发人员在 Pull Request 中修改了 200 行代码，他们至少需要覆盖其中的 120 行（假设测试覆盖率达到 100% 60%）。但这样就无需遍历大量与本次任务无关的模块。这可以解决问题。我们该如何将其应用到项目中呢？幸运的是，我们有解决方案。

Jacoco 报告已发送至测试覆盖率服务器。

SonarCloud是最受欢迎的解决方案之一。

服务器会保存之前的计算统计数据。这对于计算即将进行的变更以及整段代码的测试覆盖率非常有用。然后，分析结果会发送到持续集成 (CI) 服务器，CI 服务器再将其发送回 Git 服务器。

这种工作流程提供了一个机会，可以在产品演进的任何阶段应用强制测试的理念，因为只有新增的变更才会被验证。

说到代码风格，其实差别不大。你可以试试Checkstyle插件。它会自动判定任何违反既定要求的构建失败。例如，代码中可能存在未使用的导入语句。此外，你还可以使用一些云服务来运行代码分析，并将结果以图表的形式呈现出来（SonarCloud 也能做到这一点）。

光盘

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

让我们对 CI 架构做一些修改。这展示了 CI/CD 流程在实际项目中可能的样子。

首先，CI 服务器现在被命名为CI/CD 服务器。问题在于，CI 和 CD 作业通常都使用同一个任务管理器来执行。因此，我们正在研究这种方法。

但这并非绝对规则。例如，可以将持续集成 (CI) 任务委托给GitLab CI，将持续交付 (CD) 任务委托给Jenkins。

图表的右侧部分代表持续集成（CI），我们之前已经讨论过。左侧部分代表持续交付（CD）。CD 作业构建项目（或重用 CI 阶段生成的工件），并将其部署到最终服务器。

值得一提的是，在我们的案例中， “服务器”是一个抽象概念。例如，部署可能会进行到Kubernetes集群上。因此，可能会有多个服务器。

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

总之，这里有个重要的问题：我们应该何时运行持续交付（CD）作业？触发条件可能各不相同。

1. 每次合并拉取请求后都要部署。
2. 按计划部署。
3. 每次 Pull Request 合并到特定分支后进行部署。
4. 组合选项。

第一点规定了 CI 和 CD 作业始终按顺序运行的流程。这种方法在开源开发中相当流行。Semantic Release库有助于调整项目，从而透明地集成此流程。

了解这个deploy定义很重要。它并不一定意味着在某个地方发布某个东西。如果你开发了一个库，那么并不存在发布的情况。相反，部署过程指的是发布新版本的库。

第二点与持续集成 (CI) 流程无关。因为项目是按照预先设定的计划进行部署的。例如，每天上午01:00。

第三点与第一点类似，但也存在一些差异。假设我们的代码仓库中有两个主要分支：一个develop分支和master一个分支。第一个分支develop包含最重要的变更，而第二个分支只包含发布版本。如果我们只需要部署第一个master分支，则无需在合并到第一个分支时触发持续交付 (CD) 作业develop。

最后一点是所有方法的综合。例如，develop分支可以根据计划部署到开发环境，并master在每次合并拉取请求时部署到生产环境。

工具

市场上提供了数十种用于自动化 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流程的基础知识，我就说这么多。如果您有任何问题或建议，请在下方留言。感谢阅读！