GitLab CI/CD

GitLab CI/CD 是一个内置在GitLab中的工具，用于通过持续方法进行软件开发：

Continuous Integration (CI) 持续集成
Continuous Delivery (CD) 持续交付
Continuous Deployment (CD) 持续部署

详细介绍可以看官方文档：CI/CD 概念

持续集成的工作原理是将小的代码块推送到Git仓库中托管的应用程序代码库中，并且每次推送时，都要运行一系列脚本来构建、测试和验证代码更改，然后再将其合并到主分支中。

持续交付和部署相当于更进一步的CI，可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。

这些方法使得可以在开发周期的早期发现BUG和错误，从而确保部署到生产环境的所有代码都符合为应用程序建立的代码标准。

GitLab CI

GitLab CI是为GitLab提供持续集成服务的一整套系统。在GitLab8.0以后的版本是默认集成了GitLab-CI并且默认启用的。

使用GitLab CI需要在仓库跟目录创建一个gitlab-ci.yml的文件，它用来指定持续集成需要运行的环境，以及要执行的脚本。还需要设置一个gitlab-runner，当有代码push变更的时候，gitlab-runner会自动开始pipeline，并在gitlab上显示持续集成的结果。

GitLab Runner

那GitLab-Runner又是什么东东呢？与GitLab-CI有什么关系呢？

GitLab-Runner是配合GitLab-CI进行使用的。一般地，GitLab里面的项目会定义一个属于这个项目的软件集成脚本（gitlab-ci.yml），用来自动化地完成一些软件集成工作。当这个工程的仓库代码发生变动时，比如有人push了代码，GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个项目相关联的Runner，并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。

所以，GitLab-Runner就是一个用来执行软件集成脚本的东西。可以想象一下：Runner就像一个个的工人，而GitLab-CI就是这些工人的一个管理中心，所有工人都要在GitLab-CI里面登记注册，并且表明自己是为哪个工程服务的。当相应的工程发生变化时，GitLab-CI就会通知相应的工人执行软件集成脚本。如下图所示：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hf7G2tgs-1641727032542)(/upload/images/1641726205423_525728-4339103186d2b1c9.webp)]

GitLab-Runner执行情况如下：