Gitlab CI&CD 在前端项目自动化构建部署中的实践

引言

现在大部分的公司都搭建了自己的Gitlab，除了Git的代码管理能力，Gitlab的CI&CD在项目的持续集成和部署上也尽力提高大家的工作效率。下面用我们项目的例子为大家引荐一下这套工具带来的便利。

Gitlab CI&CD是什么

如上官方图示，可以理解为Gitlab给开发者提供了一项功能，在代码提交后自动触发一段开发者自定义的脚本，以此来完成诸如但不限于构建部署的工作。

为什么我们需要使用

1. 项目业务较多，多个业务并行联调或测试（不要问我分支怎么管理的，后面说）；
2. 不断有新人进入；
3. 测试机器时常有被更换的风险；
4. 项目依赖包时常会更新，每个人环境的依赖包小版本可能不一致。

因此我们迫切的需要一个新人低成本或零成本的、快速自动化的构建部署方案。

解决方案

1. 为环境指定不同的分支，如dev1 代表联调环境1，test2 代表测试环境2，… ，testN 代表测试环境N。如下图，各分支与环境的关系
   

2. 利用Gitlab CI&CD工具执行自动化构建，并根据分支部署到不同机器，如上图，发布到个环境前都经过了CI阶段的自动化构建等操作，线下测试和联调还可以在CD阶段自动部署到对应服务器

执行步骤

1. 在仓库里面配置.gitlab-ci.yml
2. 在可以访问git仓库的服务器部署Runner
3. 在git仓库网页上配置对应的Runner

项目配置

配置文件 .gitlab-ci.yml
在项目的根目录下创建文件.gitlab-ci.yml

Keyword	Required	Description
script	yes	CI&CD过程需要执行的shell脚本
stage	no	一个job流程,默认test
variables	no	定义变量
only	no	指定当前job适用的git refs(分支、Tag)列表
except	no	与only相反
tags	no	通过标签管理或匹配runner
allow_failure	no	指定当前job是否容错，正常job失败会跳过后续job流程
before_script	no	在当前job执行前执行的shell脚本
after_script	no	在当前job执行后执行的shell脚本
when	no	依赖的上一个job执行什么状态后执行当前job， on_success on_failure always manual 默认on_success
dependencies	no	指定依赖的job列表，默认顺序执行

查看其他可配置属性

# 执行job的阶段 按顺序串行执行
stages:
  - build
  - cleanup
  - deploy

# 自定义阶段build的job流程
build: # 自定义名字
  stage: build # 指定这阶段操作的名称
  only: # 指定那些分支会进入该处理流程
    -