关于前端:gitlabci

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

概念介绍看起来很简单，但其实整个流程都是用一个文件配置的。
在我的项目根目录下创立名为 .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"'

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

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

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

一个 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 文件相干
预约义变量

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

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

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

参考：
入门
应用

关于前端:gitlabci

一. 什么是 gitlab CI/CD

二. .gitlab-ci.yml 文件

1. pipline 管道

2. stage 阶段

3. job 作业

三. 一些 tips