GitLab CI / CD 持续集成和单元测试

发表于

这是我参与11月更文挑战的第26天，活动详情查看：2021最后一次更文挑战

前言

上一篇，主要对持续集成CI/CD的认识，这一篇主要实践操作下，解决2个问题：

  • 配置.gitlab-ci.yml
  • 接入单元测试

.gitlab-ci.yml说明

一个完整的项目的生命周期都要经历的流程：开发–打包–测试–部署。现比较流行的CI/CD手段可以有效的约束代码质量 ，完 快速部署上线。

接下来实践：基于GitLab CI / CD 持续集成Node项目

写个简单的node项目使用koa框架，增加.gitlab-ci.yml配置文件，其基本写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
yaml复制代码# 定义stages
stages:
  - build
  - test
  - deploy
#定义job
build:
  stage: build # 指向对应的stage
  script:
    - npm install
#定义job
test:
  stage: test
  script:
      - echo "start:npm run test"
#定义job
deploy:
  stage: deploy
  script:
    - echo "deploy:push the project to the Product"
​
  • 关键字 stages ：定义Pipeline 中的各个构建阶段，并使用非关键字来定义jobs，如文件中有三个jobs的定义：build、test、deploy，且执行时也将按照此顺序执行下去。
  • Job1/ Job2 非关键字意为各个Job名称，且可用关键字 stage 来指定该 Job 对应哪个 stage 。
  • 关键字 script ：每个Job 都必须有的，表示每个Job要执行的命令，主要由 GitLab Runner 执行的shell脚本。
  • 关键字 before_script 和 after_script ：是定义任何 Jobs 运行前/后都会执行的命令。

还有其他相关关键字，可以从官网上查看。了解整个基础的过程后，就可以知道怎么去设置整个集成的过程。最关键的就是script 这部分了。

CI接入单元测试

学会了持续集成，那么再增加通过CI进行单元测试，完成自动化测试工作。

根据上面所说，script 部分主要是由gitlab runner 执行shell 脚本，所以只需要在正式上线之前进行最后一次自动化测试工作就可以。所以，可以再定义一个 stage 执行单元测试 。

1
2
3
4
5
6
7
8
9
10
11
12
markdown复制代码stages:
  - unitTest
  
unitTest:
  stage: unitTest
  only:
    - dev
    - master
  script:
    - echo "unit test start"
    - yarn test
​

注意到看设置了Job.only，表示只有在dev 分支和 master 分支才会触发到相关Jobs。

未学习CI/CD之前一直都不是很了解整个过程，并且当时觉得加入单元测试是一项很难工作，无从入手。通过一番学习后，对整个CI/CD有个整体了解后就知道都是通过配置文件，并且配置文件中脚本是shell 脚本命令来完成整个工作。不仅可以实现接入单元测试，也可实现测试代码覆盖率并通过gitLab pages 显示单测的结果，甚至也是可以支持在其中进行 webhook 方式通知结果。

参考资料：

scarletsky.github.io/2016/07/29/…

\

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

0%