CICD详解(一)——概念和原理

今天继续给大家介绍Linux运维相关知识,本文主要内容是CICD的概念和原理。

一、技术背景

随着计算机技术的迅猛发展,软件工程行业蓬勃兴起。起初,一个应用软件由单个程序员独立完成。但是,随着软件需求量、代码量的增大,开发周期的缩短,原先有单个程序员完成的任务需要多个程序员合并才能完成。并且,还细分除了用于编写软件的开发工程师、用于测试软件质量的测试工程师和用于维护代码运行的运维工程师。
多人协作、任务细分能够解决一定的问题,但是不可避免的带来了协作上的混乱。例如,多人合作开发一个软件,每个人负责一个模块,但是最终将多人工作集合时发现不同人的代码之前存在冲突,不能很好的结合在一起。或者是虽然能够集合在一起正常工作,但是性能出现了很明显的下降。此外,还带来了工作效率降低的问题。现代软件开发上线后,不可避免的会出现一系列的bug,或者是随着业务的提升,原有的系统不能满足新业务的需求,也需要紧跟着提升,又或者随着依赖库、依赖环境的升级,原有的系统也不可避免的要紧跟着升级。因此,软件的生产周期就出现了一个环形的流程,即开发——测试——运维——开发新的版本……。在此过程中,随着业务规模的庞大,一个周期所需花费的时间越来越长。
传统模式下软件开发流程如下所示:
CICD详解(一)——概念和原理_第1张图片

为了解决以上种种问题,CICD技术营运而生。所谓CICD,即Continuous Integrity,Continuous Delivery,Consistent Deployment,持续集成、持续交付、持续部署。
CICD的DevOps过程如下所示:
CICD详解(一)——概念和原理_第2张图片

二、持续集成

持续集成是指在代码开发过程中,可以频繁的将代码部署到主干,并进行自动化测试。
前面我们讲到,在代码的协同开发过程中,多个开发者的代码组合起来可能会存在各种冲突和BUG。为了解决这个问题,我们就必须使得每个开发者不断的提交代码,由一个总负责人将各个开发者提交的代码进行整合,发现冲突及时处理。这样,可以避免到开发的最后进行整体的代码集成时出现灾难性的BUG而无法处理。一般而言,由项目负责人确定的代码版本我们称之为“主干”,每个小模块的程序员编写的代码我们称之为“分支”。在程序员提交自己编写的分支后并测试后,由项目负责人将各个分支合并为一起,称为新的主干。每个程序员接下来的开发就是以新的主干为基础,以此来减少代码冲突。持续集成完成了构建、单元测试和集成测试这些自动化流程。

三、持续交付

持续交付是指在持续集成的基础上,将代码部署到预生产环境。
持续交付比持续集成进步的点在于,持续交付考虑到了开发环境与生产环境之间的区别,将包括依赖库和依赖环境在内的开发环境进行打包,实现了自动部署到预生产环境中。简单的来看,持续交付可以使得开发团队在完成代码开发工作后,运维团队可以快速的进行生产环境的部署。如果说持续集成解决的是开发团队之前不同程序开发的兼容性问题,那么持续交付=是旨在解决开发和运维团队之间可见性及沟通较差的问题

四、持续部署

持续部署是指在持续交付的基础上,把部署到生产环境的过程自动化,持续交付和持续部署最大的区别就是最终部署到生产环境中是自动化的。
持续部署比持续交付更大的提升了自动化水平,使得开发团队编写的代码,可以在短时间内自动的部署在生产环境中。持续部署解决因手动流程降低应用交付速度。
原创不易,转载请说明出处:https://blog.csdn.net/weixin_40228200

你可能感兴趣的:(自动化运维,运维,Linux,zabbix,CICD,自动化)