前言

纵观人类历史的发展以及三次工业革命，你会发现利用机器来替代部分人力劳动，将重复的工作自动化从而解放生产力都是发展的必然趋势，在软件工程领域也不例外，其中 CI/CD 就是其中一项，那么什么是 CI/CD 呢，网上的解释不要太多，这里我就直接放一幅 Gitlab 官网的工作流程图好了：

准备条件

  1. Gitlab runner

  2. .gitlab-ci.yml

    Gitlab runner

    Gitlab runner 是整个 CI/CD 的执行器，它是执行你写的 .gitlab-ci.yml 文件的虚拟机。
    Gitlab runner 分为两种：
  3. 特定的 runner：只能当前项目使用

  4. 共享的 runner：所有项目都可以使用

找到你的项目在 设置>Runners 里
你可以看到如下界面：


左侧就是特定的 runners 右侧就是共享的 runners，只要确保有其一就行。
关于 runner 的安装我不想过多赘述，官网写的很清楚，只要按照步骤一步一步搭建就好了。

.gitlab-ci.yml

当你有了 runner 就可以开始着手写 .gitlab-ci.yml 文件了，.gitlab-ci.yml 文件是对于整个 CI/CD 流程的描述文件，它告诉 runner 应该怎样执行具体的操作。
在具体介绍配置之前，我想先明确整个 .gitlab-ci.yml 里面的几个重要名词：

  1. job: job 是整个 CI/CD 的核心单元，它定义了在什么条件下应该执行什么任务，每个 job 都是相互隔离的。
  2. script: job 下的属性，用于描述 job 要执行的任务。
  3. stages: 定义 job 的分组，不同 job 可以所属于不同的阶段，一共有三个阶段可供选择：test build deploy，stage 的执行是按顺序的，但是 stage 下面的 job 是并行执行的，只有前一个 stage 执行成功才会执行下一个 stage，一旦上一个 stage 中任何一个 job 执行失败都会导致整个流水线失败。
  4. pipeline: 上面的整个流程就是一个流水线。

下面是我的一个前端项目的 .gitlab-ci.yml 文件，以它来作为示例：

image: node:10.13        stages:   - test   - build   - deploy    cache:   paths:     - node_modules/      before_script:   ## set proxy   - export http_proxy=http://10.2.3.63:3128/   - export https_proxy=http://10.2.3.63:3128/  test:   stage: test   tags:     - sams   script:     - npm install --no-optional --registry=https://registry.npm.taobao.org     - npm run lint   only:     - master     - dev  build:   stage: build   tags:      - sams   script:     - npm run build   artifacts:     paths:       - $SOURCE_DIR     expire_in: 2 mins   only:     - master  deploy:   stage: deploy   tags:      - sams   before_script:     ## set debian mirros     - echo 'deb http://mirrors.aliyun.com/debian/ stretch main non-free contrib' > /etc/apt/sources.list     - echo 'deb-src http://mirrors.aliyun.com/debian/ stretch main non-free contrib' >> /etc/apt/sources.list     - echo 'deb http://mirrors.aliyun.com/debian-security stretch/updates main' >> /etc/apt/sources.list     - echo 'deb-src http://mirrors.aliyun.com/debian-security stretch/updates main' >> /etc/apt/sources.list     - echo 'deb http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib' >> /etc/apt/sources.list     - echo 'deb-src http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib' >> /etc/apt/sources.list     - echo 'deb http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib' >> /etc/apt/sources.list     - echo 'deb-src http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib' >> /etc/apt/sources.list     ## Using SSH keys with GitLab CI/CD     ## https://docs.gitlab.com/ee/ci/ssh_keys/README.html     - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'     - eval $(ssh-agent -s)     - echo "$SSH_PRIVATE_KEY" | tr -d '\r' | ssh-add -     - mkdir -p ~/.ssh     - chmod 700 ~/.ssh     - echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts     - chmod 644 ~/.ssh/known_hosts   script:     - scp -r $SOURCE_DIR $DEPLOY_SERVER_USER@$DEPLOY_SERVER_IP:$TARGET_DIR   only:     - master   environment: test

全局配置

  • image: 要使用的 docker 镜像它会根据你写的镜像名从 docker hub 上面拉取镜像，因为我们的项目是前端项目，所以这里配置的镜像是 node，最终你的 script 指定的脚本会跑在 node 的 docker 环境下，这样就保证你有了必要的环境依赖（node）
  • stages: 定义整个流水线的各个阶段，这里我三个阶段都定义了，但是你可以根据你自己项目的实际情况定义，定义好后流水线将按照你定义的顺序依次执行。
  • cache: 定义 job 之间要缓存的文件，通常我们都会把项目的安装依赖作为缓存，这样下一个 job 就不用重新安装依赖了

  • before_script: 定义所有 job script 执行前需要执行的脚本，这里我设置了代理。

    job 的配置

  • stage: 定义该 job 所属的 stage
  • tags: 指定该 job 使用的 runner
  • script: 该 job 需要执行的脚本
  • only: 该 job 的约束条件，你可以指定该 job 在哪些情况下会触发，比如只有 master 分支和 develop 分支才会执行 deploy 的 job，与此相对的还有一个 except 属性表示什么条件下不执行该 job
  • artifacts: 用于在不同 stage 之间传递结果，通用的做法是将 build 阶段打包出来的文件定义为 artifacts，这样在 deploy 阶段就可以直接使用了，这里你可能会对 artifacts 和 cache 有些搞不清，这里推荐看官方的说明

  • environment: 用于定义 job 部署的环境，这里需要结合 Gitlab 项目的 UI 界面，比如这里我设置的名称叫 test，每次部署成功之后 test 环境下就会多一个部署条目，你可以重新部署甚至回滚到某个部署，如下图所示：

另外 environment 下还有一个 url 属性可以定义部署到的服务器地址，这样你可以在 UI 界面通过点击按钮直接跳转到项目，如果你的 Gitlab 低于 8.11 那只能通过在 UI 界面（上图）手动配置了。