首先介绍下什么是CICD

CI/CD 是一种持续开发软件的方法，可以不断的进行构建、测试和部署代码迭代更改。这种迭代有助于减少基于错误或失败的版本进行开发新代码的可能性。使用这种方法，从新代码开发到部署，可以减少人工干预甚至不用干预。

达到持续的方法主要是：持续集成，持续交付，持续部署。

传统的自动化部署的流程

1.git的CICD自动化部署 这个只要在代码的根目录有.gitlab-ci.yml，GitLab将检测到该文件，并使用名为GitLab Runner的工具运行你的脚本，那至于怎么部署，完全在这脚本里面实现，可以执行脚本了，那做啥都可以了，那前端举例：先是npm install，然后build，最后就是你用vm部署还是docker部署，就是上传文件的事情了，这里就不再赘述了，网上资料很多。

2.Jenkins的CICD自动化部署 这个就很常见了，感觉大多数企业都是采用这个的，（就算是open shift里面，我要说的也是Jenkins的方式，虽然open shift有自己的pipeline）。他的流程很固定：

1）第一步配置git的仓库，这步是下载git上面的代码为下面编译准备的（前置要配置好git的用户名和密码）

2）还是前端例子，选择nodejs的build环境（前提下载node的插件，配置好node的工具），然后就是npm install,npm build 了

有一点需要注意的是，在这里面直接写npm或者node命令会报错，所有一般会在下面添加个shell的命令来执行npm install,build等打包操作。

3）接下来就是部署的环节了，你可以在VM虚拟机上部署，比如这虚拟机上有nginx或者apache等web服务器，那你就可以直接SSH把包传到web服务器所需要的目录中了（配置下ssh就行）。如果你要使用docker部署前端的话就需要docker build这一步

这步就是根据你代码里面配置的dockerfile文件来进行docker build打包镜像了，很明显这边需要dockerfile还有一个cloud，这个很重要。比如你在自己电脑上怎么打包镜像的呢，是不是需要docker环境，执行docker命令，那我们这个Jenkins的服务器上你直接执行docker明天肯定没反应。那我们需要第一步下载docker插件，第二步配置docker环境

这就是配置docker环境的（前提你得有docker环境，然后运动docker时开启2375）。

ExecStart=/usr/bin/dockerd -H unix://var/run/docker.sock -H tcp://0.0.0.0:2375

记得这个最后注意下安全性，开这个端口。这个有配置docker push到具体仓库的。如果你直接是docker run的就ssh到部署的机器上下载最新镜像然后重新run。如果你是使用docker-compose的话，就比较简单，直接docker-compose pull && docker-compose up -d,至此大多数的CICD就结束了。

open shift的CICD的流程

这才是本次的重点，因为正常的CICD网上一搜一大把，但是红帽的文档比较少也乱，之前和红帽人员沟通的抱怨到，他们也说是的，以后加强这块的。那open shift流程是什么：

这两个图就是整个的流程，接下来我们就来看看流程

1.首先还是gitea是源头，保存代码的，当你上传完代码后，在gitea里面配置一个webhook来钩子Jenkins

2.紧接着上面的gitea钩子触发了Jenkins的pipeline了，开始往下走，下载gitea的代码（具体和传统一样）

3.下一步就是sonarqube了，这步是代码的检查，使用sonarqube做代码问题检测，这步中需要配置sonarqube插件，地址和key

4.这步就是JUnit，单元测试，前端的话也是需要写函数或者页面的单元测试的，也就在这步执行

5.接下来就是代码的编译打包了，这和传统的一样，没什么区别

6.这步开始就不同了，docker镜像的制作，传统就有VM虚拟机可以配置docker环境的，但是open shift我们需要做网络隔离，其实他这边镜像内部权限很低，别说root权限了，就连1001都没有，一般都是几万，这样会使得你之前在本地制作的镜像可以运行，但是到了open shift里面就是各种没权限，启动报错了，这是open shift的机制，他不允许高权限的他是和severaccount绑定的。 说了这么多想表达的就是这步和往常不一样的要么你打通网络，有台VM给你用。要么就是使用open shift自己的build config来制作镜像了。 build config：

• Git
• Dockerfile
• Binary
• custom

这是他的4种方式，Git的话就是S2I，可以看看source to image，这时在open shift建立build config配置，然后在Jenkins执行start-build来触发你刚创建的build config来实现镜像制作。

7.这步是镜像的安全扫描了可以使用open shift自己的ACS或者prisma cloud

8.这步执行import-image。那这是干嘛的呢，我们先是通过deploymentConfigs来创建一个app,这是会启动pod，这时你配置这个deploymentConfigs时采用imagestreamTag这个方式，刚才的import-image就是更新这个imagestreamTa，当imagestreamTa更新了，deploymentConfigs会收到，然后重新启动pod，至此流程就全部结束了

上面还有一些其他分支的流程就不详细说了，这是多环境的流水部署，dev,sit,uat等 至于nexus，gitOps就不多说了，这是版本管理，还涉及到怎么并发的往阿里云推也不多说了，流程大致是这样，细节的话，每个项目的要求不一样