gitlab-ci

一. 什么是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.0

stages:
  - security_check
  - release_verify
  - update_beta
  - update_live

security_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_requests

update_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当前被操作的分支名。

参考：
入门
使用