GitLab CI入门及实践操作

前言

假如我们有一个项目，已经部署在服务器上面了，然后但是我们想要修改其中的一个页面的部分功能，我们需要做些什么事情呢？

• 先拉取gitlab上的代码
• 对代码进行修改开发
• 测试代码是否正常运行
• 打包我们的前端代码
• 将代码重新上传服务器【要是是第一次部署服务器，那你得在服务器上安装你的项目所需要的环境，比如node，还得维护环境】
• 在服务器上看代码是否正常运行
• 提交代码

这样一看，非常麻烦，但凡我们想要修改一点儿东西都得经历上述步骤，时间也浪费了，也没法保证每次提交服务器都是正常运行的。

所以我们有了GitLab CI,让我们关注于开发，而不是这些提交部署的流程，直接一键上传，自动部署

---

1.什么是GitLab CI?

GitLab CI/CD是一个GitLab工具，是基于GitLab的CI/CD系统，用于持续方法进行软件开发，CI/CD就是一个流程（也称管道）

• 持续集成 (CI)：指的是，频繁地（一天多次）将代码集成到主干。
• 持续交付/持续部署 (CD):当开发人员在主分支合并一个提交时，这个分支将被构建，测试，如果一切顺利，则部署到生产环境中

从GitLab8.0开始，GitLab全面集成了GItLab-CI,且对所有项目默认开启。只要在项目仓库的根目录添加 .gitlab-ci.yml 文件，并且配置了 Runner （运行器），那么每一次合并请求（MR）或者 push 都会触发 CI pipeline

每次推送时，都要运行一系列脚本来构建、测试和验证代码更改，然后再将其合并到主分支中。持续交付和部署相当于更进一步的CI，可以在每次推送到仓库默认分支的同时将应用程序部署到生产环境。

意思是把测试、打包、发布都交给自动化的工具，提高效率，减少失误，开发人员只需要开发和提交代码到git就可以完成后续工作

2.基础概念

（1）Pipelines

是CI/CD的最上层组件,就是流水线，一次Pipeline 其实相当于一次构建任务，可以包含安装依赖、运行测试、编译、部署等流程，任何提交或者Merge Request的合并都可以触发Pipeline

（2）Stages

一次Pipeline 中可以有多个Stages,一个Stages失败，后面就都失败，构建Pipeline也就失败

+--------------------------------------------------------+
|  Pipeline                                              |
|  +-----------+     +------------+      +------------+  |
|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |
|  +-----------+     +------------+      +------------+