关于java:软件开发常说的CICD是什么

6次阅读

共计 3448 个字符，预计需要花费 9 分钟才能阅读完成。

本文翻译自国外论坛 medium，原文地址：本文翻译自国外论坛 medium，原文地址：https://medium.com/gitconnected/basics-of-ci-cd-a98340c60b04

任何软件我的项目的次要指标都是通过业务流程疾速更新迭代来赚钱。咱们越快向客户公布新版本，对咱们的公司就约有益处。但如何疾速实现版本更新迭代呢？咱们能够手动实现。例如能够通过 SSH 连贯到近程服务器。而后咱们能够应用新代码克隆代码库、构建它并应用命令行运行它。只管这个形式的确无效，但这并不是一种便捷的办法。

因而本篇文章咱们将探讨如何将产品公布和开发过程实现自动化。

本文题目所写的 CI 和 CD 是两个缩写，别离代表继续集成和继续交付。

CI：继续集成形容了代码库变更的过程。让咱们看一个简略的模式，它给出了团队开发的示例。

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

咱们如何晓得进入 master 分支的代码能够编译通过？
咱们心愿开发人员为代码编写测试。咱们如何验证测试覆盖率没有降落？
所有团队成员都应应用指定的代码格调来格式化代码。咱们如何查看可能存在的违规行为？

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

为了实现以上几点，咱们能够把所有形容的要求都进行手动验证。不过这种办法非常复杂，当代码库越来越宏大时，这个形式并不可取。

于是乎 CI 的呈现是为了实现以上所提出的几点倡议并将其自动化。

第一点，咱们如何晓得进入 master 分支的代码能够编译通过 ？

咱们须要在架构中增加另一个模块，如下图。

大多数 CI 流程都能够依据这个架构来形容。

每次关上 Pull 申请（以及推送新更改）时，Git 服务器都会向 CI 服务器发送一条告诉。
CI 服务器克隆代码库，检出谬误分支（例如 bugfix/wrong-sorting 分支），并与主分支合并。
而后构建脚本将被启动。例如 ./gradlew 脚本执行构建操作。
如果上一步脚本命令返回 0 代码，则构建胜利。否则视为失败。
CI 服务器将带有构建后果的申请发送到 Git 服务器。
如果构建胜利，则容许合并 Pull 申请。否则合并将被阻止。

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

第二点，咱们心愿开发人员为代码编写测试。咱们如何验证测试覆盖率没有降落？

让咱们把工作变得更简单。假如咱们要设置最小测试覆盖率。任何时刻 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 流程的解决方案。让咱们看一下其中的一些。

Jenkins。世界上最受欢迎的 CI/CD 工具之一。因为其开源政策，它变得十分受欢迎。咱们无需领取任何费用。Jenkins 容许应用 Groovy 强制形容构建管道。一方面，它提供了更多的灵活性。但另一方面，它也须要更高的能力程度。
GitHub Actions。CI/CD 工具蕴含在 GitHub 和 GitHub Enterprise 中。与 Jenkins 不同，GitHub Actions 提供带有 YAML 配置的申明式构建。此外，该解决方案与不同的质量保证零碎（例如 SonarCube）进行了大量集成。因而，构建只需几行文本即可形容。
GitLab CI。它与 GitHub Actions 十分类似。尽管如此，它还是有其非凡之处。例如 GitLab CI 能够指出构建失败的特定测试。
Travis CI。云 CI/CD 服务。它提供了许多不须要简单配置的性能。例如对应该暗藏在公共代码库中的数据进行加密。此外一个不错的益处是 Travis CI 能够完全免费地利用于 GitHub、GitLab 和 BitBucket 中的开源我的项目。

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