使用gitlab-ci集成前端项目

Posted on Edited on

前言

这几天正好有空（划水）在研究ci方面的一些基础知识 主要是对着官方文档做参考并加以实践
先介绍一下小弟对于gitlab-ci的认知（免责声明）

  1. 开发者通过配置gitlab-ci.yml文件 在每次代码产生push或者有新的tag产生时触发ci脚本
  2. gitlab-ci集成流程由多个job组成， 每个job跑在不同的gitlab-runner中， 也可以多个job形成依赖关系 这点倒跟docker有类似的地方

怎么用

官方文档

文档讲解的很清楚 这里不多赘述了 主要就是几个参数的使用 如下图所示：
gitlab-ci

本次我们以前端项目的自动化为例，做一个简要的介绍
我司的前端项目构建时主要有三个阶段 test、build、deploy

  1. test阶段主要负责做一些单元测试、代码lint检查等
  2. build阶段负责将代码打包发到CDN 并根据打包文件生成项目配置文件
  3. deploy阶段负责 从生成的配置文件中获取最新的静态资源地址 并保存到redis中 以便node服务器去获取最近一次的发版内容

实际情况远比这些上述要复杂的多 但是本次我们讲的是gitlab-ci用法 下面我会举个demo 包教不包会嘿嘿😋
如图
gitlab-ci

这是一个常规项目的ci流程
图中将ci分为三个阶段 Test、Build、Deploy 接下来我会依据这三个阶段实践一下

我们在项目中创建index.js
目标是达到能通过不同的分支去构建不同的环境变量从而打印出不同的env名
内容如下:

1
2
const env = process.env.NODE_ENV
console.log(`${env}, 蔡徐坤`)

在package.json scripts中加入

1
2
3
{
  "build": "export NODE_ENV=$CI_ENVIRONMENT_NAME && node index.js"
}

再新建.gitlab-ci.yml文件
内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
image: xxxx    // 通常是docker-node镜像

stages:
  - build
  
build:
  stage: build
  script:
    - npm run build
  environment:
    name: build
  tags:
    - 2B
  only:
    - master@xxxx

上面的job 会在master分支push代码后触发npm run build命令
environment的name参数对应package.json中的$CI_ENVIRONMENT_NAME参数
所以我们可以进一步通过ci提供的模板功能来达到不同分支触发不同构建参数的目的

如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
.build-template: $build-template
  stage: build
  script
    - npm run build
  tags:
    - 2B
    
build-dev:
  <<: *build-template
  environment:
    name: alpha
  only:
    - dev@xxxx  
    
build-beta:
  <<: *build-template
  environment:
    name: beta
  only:
    - dev@xxxx

总结

gitlab-ci的用法自由度非常高 这种持续集成方案的出现让开发者在部署方面节省了很多成本。