前端VUE基于gitlab的CI

CI
1.Gitlab的CI
2.CI/CD VUE应用

CI

持续集成指的是，频繁地（一天多次）将代码集成到主干。

持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

1.Gitlab的CI

从 GitLab 8.0 开始，GitLab CI 就已经集成在 GitLab 中，我们只要在项目中添加一个 .gitlab-ci.yml 文件，然后添加一个 Runner，即可进行持续集成。而且随着 GitLab 的升级，GitLab CI 变得越来越强大。

首先明白Gitlab CI 几个基本的概念

1.1 GitLab-Runner

这个是脚本执行的承载者，.gitlab-ci.yml的script部分的运行就是由runner来负责的。GitLab-CI浏览过项目里的.gitlab-ci.yml文件之后，根据里面的规则，分配到各个Runner来运行相应的脚本script。这些脚本有的是测试项目用的，有的是部署用的。

1.2 .gitlab-ci.yml

这个是在git项目的根目录下的一个文件，记录了一系列的阶段和执行规则。GitLab-CI在push后会解析它，根据里面的内容调用runner来运行。

简单来说就是，你利用Git版本管理Push了本地代码到Remote上(这里就是你gitlab.com)，然后Gitlab，就通知你的服务器，也就是Gitlab-runner来运行构建任务。然后跑测试用例，测试用例通过了就生成Build出相应的环境的代码，自动部署上不同的环境服务器上面去。

1.3 配置.gitlab-ci.yml

配置好 Runner 之后，我们要做的事情就是在项目根目录中添加 .gitlab-ci.yml 文件了。当我们添加了 .gitlab-ci.yml 文件后，每次提交代码或者合并 MR 都会自动运行构建任务了。

在.gitlab-ci.yml有一些需要讲解的概念

1.3.1 Pipeline概念

一次 Pipeline 其实相当于一次构建任务，里面可以包含多个流程，如安装依赖、运行测试、编译、部署测试服务器、部署生产服务器等流程。我们的任何提交或者 Merge Request 的合并都可以触发 Pipeline。如下图：

+------------------+           +----------------+

|                  |  trigger  |                |

|   Commit / MR    +---------->+    Pipeline    |

|                  |           |                |

+------------------+           +----------------+

1.3.2 Stages

Stages 表示构建阶段，说白了就是上面提到的流程。

我们可以在一次 Pipeline 中定义多个 Stages，每个Stage可以完成不同的任务。

Stages有下面的特点：

所有 Stages 会按照顺序运行，即当一个 Stage 完成后，下一个 Stage 才会开始

只有当所有 Stages 完成后，该构建任务 (Pipeline) 才会成功

如果任何一个 Stage 失败，那么后面的 Stages 不会执行，该构建任务 (Pipeline) 失败

因此，Stages 和 Pipeline 的关系就是：

+--------------------------------------------------------+

|                                                        |

|  Pipeline                                              |

|                                                        |

|  +-----------+     +------------+      +------------+  |

|  |  Stage 1  |---->|   Stage 2  |----->|   Stage 3  |  |

|  +-----------+     +------------+      +------------+  |

|                                                        |

+--------------------------------------------------------+

1.3.3 Jobs

Jobs 表示构建工作，表示某个 Stage 里面执行的工作。

我们可以在 Stages 里面定义多个 Jobs，这些 Jobs 会有以下特点：

相同 Stage 中的 Jobs 会并行执行

相同 Stage 中的 Jobs 都执行成功时，该 Stage 才会成功

如果任何一个 Job 失败，那么该 Stage 失败，即该构建任务 (Pipeline) 失败

所以，Jobs 和 Stage 的关系图就是：

+------------------------------------------+

|                                          |

|  Stage 1                                 |

|                                          |

|  +---------+  +---------+  +---------+   |

|  |  Job 1  |  |  Job 2  |  |  Job 3  |   |

|  +---------+  +---------+  +---------+   |

|                                          |

+------------------------------------------+

2.CI/CD VUE应用

2.1 创建dockfile文件

FROM node:lts-alpine as build-stage

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

RUN npm run build

# production stage

FROM nginx:stable-alpine as production-stage

COPY --from=build-stage /app/dist /usr/share/nginx/html

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

该docker配置摁键拉取node镜像，用来编译我们的生产环境的应用，第二阶段拉取nginx的镜像用来运行我们第一阶段构建的编译应用。

执行daemon off的原因

加上了daemon off，nginx才能一直在后台持续运行，否则就会被docker进程终止，因为docker默认会终止pid为1的进程。Docker 容器启动时，默认会把容器内部第一个进程，也就是pid=1的程序，作为docker容器是否正在运行的依据，如果 docker 容器pid=1的进程挂了，那么docker容器便会直接退出。

Docker未执行自定义的CMD之前，nginx的pid是1，执行到CMD之后，nginx就在后台运行，bash或sh脚本的pid变成了1。

所以一旦执行完自定义CMD，nginx容器也就退出了。

2.2 创建.gitlab-ci.yml文件

image: docker

services:

  - docker:dind

stages:

  - deploy

step-deploy-prod:

  stage: deploy

  script:

    - docker build  -t app/sgms.web  .

        # 这里是查看当前的服务器上有没有正在运行或者存在我们之前运行过的项目容器，如果有删除了

    - if [ $(docker ps -aq --filter name=sgmsweb) ];then docker rm -f sgmsweb;fi

    - docker run -d -p 81:80 --rm  --name sgmsweb app/sgms.web

  only:

    refs:

      - main

  tags:

    - sgmsweb

2.3 注册git runner

网上资料很多，自行解决。

2.4 流水线编译成功

线上也出现了我们想要的登录页面

参考文章

How to auto deploy a Vue application using GitLab CI/CD on Ubuntu 18.04

前端的gitlab的ci初尝试