CICD介绍「建议收藏」

大家好，又见面了，我是你们的朋友全栈君。

CICD

一 概要

CICD的采用改变了开发人员和测试人员如何发布软件

在这里插入图片描述

最初是瀑布模型，后来是敏捷开发，现在是DevOps，这是现代开发人员构建出色的产品的技术路线。

随着DevOps的兴起，出现了持续集成（Continuous Integration）、持续交付（Continuous Delivery） 、持续部署（Continuous Deployment） 的新方法。传统的软件开发和交付方法正在迅速变得过时。

从历史上看，在敏捷时代，大多数公司会每月，每季度，每两年甚至每年发布部署/发布软件。然而，现在，在DevOps时代，每周，每天，甚至每天多次是常态。当SaaS正在占领世界时，尤其如此，您可以轻松地动态更新应用程序，而无需强迫客户下载新组件。很多时候，他们甚至都不会意识到正在发生变化。开发团队通过软件交付流水线（Pipeline）实现自动化，以缩短交付周期，大多数团队都有自动化流程来检查代码并部署到新环境。今天，我们将介绍什么是CI / CD / CD，以及现代软件公司如何使用工具将部署代码的流程自动化。

二 名词解释

持续集成

持续继承的重点是将各个开发人员的工作集合到一个代码仓库中。通常，每天都要进行几次，主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。

持续交付

持续交付的目的是最小化部署或释放过程中固有的摩擦。它的实现通常能够将构建部署的每个步骤自动化，以便任何时刻能够安全地完成代码发布（理想情况下）。

持续部署

持续部署在持续集成的基础上更进一步，指将推送指仓库默认分支的部署至产品环境。如果这部分需要手动触发，这就是一个持续交付（Continuous Delivery）环节。

在这里插入图片描述

三 名词详解

1. CI

CI (Continuous Integration) 持续集成,开发人员可以通过持续集成将开发的代码持续的提交到公共的代码仓库中.开发人员可以在任何时候多次的提交自己开发的代码,而并不是独立的开发某一个独立模块并在开发周期结束的时候一起提交.

这里就是为了让开发人员可以更快,更频繁的提交自己的代码,从而降低成本. 传统开发中, 在开发过程中自己提交的代码和新提交的代码会存在冲突的地方,或者你的提交的代码和你的同时的代码存在冲突时,那么在提交时才会发现你的代码和其他的代码存在冲突. 持续集成中,就可以快速的避开这样的问题,更早的提交自己的代码的.与其他的开发的代码集成,就会更快的发现问题.那么冲突的问题就可以更早的解决,降低了集成的成本

当然许多组织发现这种集成会变得昂贵.因为他们需要手动的过程来确保新代码不会引入新的错误,并且不会破坏现有代码。 为了减少集成任务期间的摩擦，持续集成依赖于测试套件和自动化测试执行

持续集成的目的就是将集成简单化,简化了重复的日常开发任务,并在开发周期的最在时间发现问题.并且发现bug并及时的解决.

2. CD

CD(Continuous Delivery) 持续交付.其实就是CI的扩展.将CI进一步自动化.可以更方便的进行项目的部署.

CD集中依赖于部署流水线.可以通过流水线自动化的测试和部署 持续交付的本质就是将每一个构建成功的引用交付给用户去使用,在持续交付的认识中,不单是测试的完成,而是交付到客户的手中. 注意: 持续交付不是持续部署(Continuous Deploy) 因为部署也包括部署到测试环境中,而持续交付时表示一个具体的功能上线,用户可以使用的.

持续交付的好处 可以快速的获取的用户的反馈.适应市场变化和商业策略的变化。开发团队保证每次提交的修改都是可上线的修改，那么决定何时上线，上线哪部分功能则完全由产品业务团队决定

CD(Continuous Deployment) 持续部署

持续部署扩展了持续交付，以便软件构建，在通过所有测试时自动部署。在这样的流程中，不需要人为决定何时及如何投入生产环境。CI/CD 系统的最后一步将在构建后的组件/包退出流水线时自动部署。此类自动部署可以配置为快速向客户分发组件、功能模块或修复补丁，并准确说明当前提供的内容 采用持续部署的组织可以将新功能快速传递给用户，得到用户对于新版本的快速反馈，并且可以迅速处理任何明显的缺陷。

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/146014.html原文链接：https://javaforall.cn