CI/CD —— 持续集成、持续交付、持续部署的了解

简介

CI / CD 改变了开发人员和测试人员如何发布软件。
由最初的 瀑布模型 ，到 敏捷开发 ，再到现在使用的 DevOps。随着 DevOps 的兴起，出现了 持续集成（Continuous Integration）、持续交付（Continuous Delivery）、持续部署（Continuous Deployment） 的新方法。
从敏捷开发时期看，大多数公司都是每月、每季度或者每年发布/部署软件；但是现在在 DevOps 时代，每周甚至每天多次都是常态。现阶段可以动态更新应用程序，而无需强迫客户下载新组件，很多时候用户甚至都不会意识到正在发生变化。

持续集成： 将每个开发人员的工作集合到一个代码仓库中。该操作每天要进行几次，目的是尽早发现集成错误，使团队之间紧密结合，能够更好的协作。
持续交付： 最小化部署或释放过程中固有的摩擦。通常能够将构建部署的每个步骤自动化，以便任何时候能够安全的完成代码发布。
持续部署： 更高程度的自动化，无论何时对代码进行重大更改，都会自动进行构建/部署。
该阶段中每一个都是交付管道的一部分。该过程涉及构建软件，然后通过多个测试和部署阶段进行这些构建。反过来，这需要许多人之间的合作，也许需要几个团队之间的合作。部署管道对此过程进行建模，并且它在持续集成和发布管理工具中的实现，使其能够在从版本控制转移到各种测试和部署，在向用户发布时查看和控制每个更改的进度。

CI（持续集成）

通过持续集成，开发人员可以多次将代码集成到公共代码仓库的主分支中，而不是像以前一样在每个功能模块开发周期结束时一一提交。
CI 的目标是将集成简化为一个简单、易于重复的日常开发任务，这有助于降低总体的构建成本，并能够在早期发现开发代码的缺陷。因此鼓励频繁迭代构建，可以早些发现 bug 并及时解决。

CD（持续交付、持续部署）

持续交付

持续交付 可以称为之 CI 的扩展，其中对于软件交付做了进一步的自动化，使其可以轻松的部署到生产环境当中。

CD 集中依赖于部署流水线，团队通过流水线自动化测试和部署过程。该流水线是一个自动化的系统，能够有针对性的构建一组渐进的测试套件。
其中 CD 具有高度的自动化，并且在一些云计算环境中也易于配置。

在流水线的每个阶段，如果构建无法通过关键测试会像团队发出警报。否则将进入下一个测试，并在连续通过测试后自动进入下一个阶段。流水线的最后一个部分会将构建部署到和生产环境等效的环境中。这是一个整体的过程，因为构建、部署和环境都是一起执行和测试的，它能让构建在实际的生产环境可部署和可验证。

$持续交付的吸引力主要在于，它自动化了从提交代码到仓库，再到测试和发布产品过程的所有步骤。这是构建和测试过程细致的自动化。那么如何发布以及发布之后的操作，就需要接下来所学习的持续部署来完成。$

持续部署

和 持续交付 类似，持续部署 则是在 持续交付 的基础上进行扩展，来完成软件的构建。

在流水线完成之后，我们不需要人为的去决定何时、何种方式去投入生产环境。CI/CD 系统的最后一步在构建后的组件/包退出流水线时进行自动部署。该自动部署配置为能够快速的向客户分发组件、功能模块或修复补丁，并准确说明当前提供的内容。

采用 持续部署可以将新功能快速传递给用户，得到用户对于新版本的快速反馈，以便于迅速处理出现的明显的缺陷。
而随着 DevOps 的发展，众多新的用来实现 CI/CD 流水线自动化工具也在不断的涌现，这些工具和各种开发工具进行配合完成一系列的操作。目前我们使用最多的是 jenkins 自动化工具。

若想了解 jenkins 自动化工具可以跳转到该博客：https://blog.csdn.net/m0_37868230/article/details/106862267