一. 什么是gitlab CI/CD

Gitlab CI/CD 是GitLab内置的一款用于继续集成（CI），继续交付（CD）的工具。
也就是说，在gitlab创立一个我的项目，就会主动领有CI/CD的性能。
这个性能能够用来做什么？
其实就是在咱们提交了代码到近程仓库，对代码做出一些变更的时候，通过配置.gitlab-ci.yml文件，gitbal能主动找到这个文件，并依据文件中的内容，对咱们提交的代码做一系列工作，比方自动检测（code lint）、构建和进行单元测试。
作用是什么呢？
有时提交的代码可能会有一些bug，如果不进行这样的检测，后续的提交就会是在之前bug的根底上做出的。所以这个性能能够帮忙开发人员确保提交的代码品质，提前查出bug。

二. .gitlab-ci.yml文件

概念介绍看起来很简单，但其实整个流程都是用一个文件配置的。
在我的项目根目录下创立名为.gitlab-ci.yml的文件，当咱们提交代码，gitlab-ci就会依据这个文件里的配置，进行相干操作。

文件样例：

image: node:14.17.0stages:  - security_check  - release_verify  - update_beta  - update_livesecurity_check_job:  extends: .model-x-check  stage: security_check  variables:    CHECK_NO_ERROR: "true"release_verify:  stage: release_verify  script: |-    result=`curl --request POST 'http://deploy-platform.shopee.io/apis/release/v1/gitlab/merge_request/verify' --header 'Content-Type: application/json' -d "{\"merge_request_id\": $CI_MERGE_REQUEST_IID,\"project_id\": $CI_PROJECT_ID}"`    echo $result;    echo $result | grep '"pass":true'  only:    - merge_requestsupdate_beta_job:  stage: update_beta  script:    - npm set registry https://npm.shopee.io/    - yarn install    - node ./fileA.js ${CI_COMMIT_REF_NAME} ${GIT_PUSH_TOKEN} ${CI_COMMIT_MESSAGE}  rules:    - if: '$CI_COMMIT_REF_NAME == "master" && $CI_PIPELINE_SOURCE == "web"'update_live_job:  stage: update_live  variables:    GIT_DEPTH: full  script:    - npm set registry https://npm.shopee.io/    - yarn install    - node ./fileA.js ${CI_COMMIT_REF_NAME} ${GIT_PUSH_TOKEN} ${CI_COMMIT_MESSAGE}  rules:    - if: '$CI_COMMIT_REF_NAME == "release" && $CI_PIPELINE_SOURCE == "web"'

文件中须要配置的波及到几个概念：

1. pipline管道

每个推动到近程仓库的提交，就是一个独自的管道。

2. stage阶段

一个管道是由多个stage组成的。默认状况下，前一个stage失败了，前面的stage就不会再执行。

3. job作业

一个job就是最终会被运行的指令汇合。一个job会被关联到一个stage，就代表这个job会在该阶段被执行。在job中，就是定义会被运行的脚本script的中央。

联合这三个概念，再看文件中的关键字：

  • stages：定义一个pipline须要运行的阶段。写的程序就是会被执行的程序。

  • job：自定义job的名字，每个job下，就须要配置以下：

    • stage字段，即它会在哪个阶段被执行。
      script字段，是一系列执行的脚本命令。
      only/except/rules字段：决定这个job会不会被创立执行。

stages和job的定义很简略，在job的定义下，须要关注script和rules
script就是一系列自定义的命令，在这个阶段的job中，想对代码做什么工作，就能够在这里以命令的模式书写，gitlab-ci就会执行。能够是一行shell脚本命令，如果逻辑很简单，能够应用node执行一个文件。
官网上有说，rules是作为only/except的代替的一个新的计划。
当rules下的一个if匹配到的时候，这个job才会被创立。在rules中，能够是以下模式的规定：
比方 只有当提交的分支是xxx，才执行job；只有是从gitlab ci的页面上通过点击'run pipline'按钮进行的管道，才执行job；
在rules中，能够应用gitbal-ci的预约义的变量，拿到提交的分支等一系列信息，做匹配工作。

具体如何配置，能够参考以下官网链接：
抉择何时运行job
.gitlab-ci.yml文件相干
预约义变量

三. 一些tips

我的项目操作过程中，master分支和release分支是比拟重要的。
通常的操作是，master分支会用于部署staging环境，进行多个需要合并后的测试。测试全副通过，正式发版的时候，用master分支笼罩release分支，最初用release分支上的代码去发版。

所以为了确保最初发版不出错，咱们能够借助gitlab-ci工具，在有代码改变提交至master分支、release分支的时候，做一些校验工作。

无效应用预约义变量：在job的定义中，咱们能够借助ci预约义好的变量，比方样例中的 CI_COMMIT_REF_NAME ，示意project以后被操作的分支名。

参考：
入门
应用