浅谈CICD原理和工作流程

15,058

简介

提到自动集成与部署,就必须了解一下DevOps。
DevOps是2008年的时候在一场敏捷开发者大会上被第一次提出来的,是为了通过自动化的方式对“软件交付”的流程进行有效管理,目的就是让构建、测试、发布等环节能够更加快速、稳定可靠

CI是“持续集成”,CD是“持续部署”的意思。一般“CICD”是合称,无需特意区分二者区别。
他解决的问题是从开发、代码检查、测试到上线的过程中,借助CICD的能力,进行一些自动化处理,保证项目交付质量的同时,降低RD/QA/OP的维护成本。

原理

CICD目前为止都是与git集成在一起的,可以理解为服务器端的git hook
可以通过git的hooks命令来在关键阶段处理事务。
在git这样的平台上可以设置web hook的地址,这个地址一般是用来通知你的runner执行集成命令的,当项目发生变化的时候就开始通知执行workflow。

工作流程

DevOps

说到流程,我们来简单看一下DevOps。 1EB1E6EA-F538-402C-9221-DBF534428464.png

当代码 master/push 到远程仓库后,借助 **WebHooks** 对当前代码在构建服务器中进行自动操作,常规操作一般是**代码检查**、**测试**、**构建**、**部署**和**监测**等。
你当然也可以添加更多自定义的job在这个workflow中。

但是实际的业务中,开发人员一般在test、dev的环境中,执行push/master这种影响分支变化的hook时,才进行以上操作。

术语

runner: 用来执行 CI/CD 的构建服务器。
workflow:CICD的工作流程。
job:就是任务,比如构建任务、测试任务和部署任务。每个 workflow 由多个 job 组成,而每个job又有多个step。
step: 多阶段。比如:npm i/npm build等。
webhook: 它就是一种异步编程模型中的类似“订阅发布”模型,简单理解就是“用户自定义的HTTP的服务”,或者叫“用户自定义的HTTP的回调”。

实践

如果是练手的小伙伴,可以使用github官方提供的actions来免费部署,性能相当可以的。如果是企业用户的话,你需要创建属于自己的runner。

环境依赖

如果你用的是GitLab服务,那么你可以使用GitLab-Runner。

  • Node 安装项目依赖、打包都需要,会自动安装npm包管理工具。
  • Nginx web 项目部署必备、 GitLab 也会用到 Nginx。
  • Git 自动化集成中,需要对代码进行管理和钩子访问。
  • GitLab-Runner 配合 GitLab CI/CD 使用的应用程序