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

Gitlab runner 是整个 CI/CD 的执行器，它是执行你写的 .gitlab-ci.yml 文件的虚拟机。
Gitlab runner 分为两种：

1. 特定的 runner：只能当前项目使用
2. 共享的 runner：所有项目都可以使用

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

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

当你有了 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

类似于编程中的变量，环境变量可以存储一些要要变化的或是比较私密的信息，环境变量配置好后可以通过 $ + 变量名 在 script 里面进行调用

在 Gitlab 主页找到流水线页签，打开之后就能看到所有流水线的运行情况

点击进入具体的 stage 你可以看到其执行细节，如果失败也可以重新执行

https://docs.gitlab.com/ee/ci/README.html

这次也是我初次尝试使用 Gitlab CI/CD ，每次任务大概执行需要 8 分钟，如果你像之前手动去做这些工作那你每次都至少需要花费 8 分钟时间，不要小瞧这 8 分钟，日积月累也是一笔不小的开支，更重要的是机器很少出错的，但是人的话就没法保证了，而且就像我在开篇所说简单重复性的工作必然会被机器取代，这是不可避免的历史规律，不管你用不用它，技术的潮流都会不断向前推动，所以还不如提前拥抱它。
另外此次只介绍了整个 Gitlab CI/CD 功能的冰山一角，Gitlab 还提供很多优秀的功能，比如在 merge request 的时候进行 CI/CD，所以更多的功能还有待挖掘，如果你感兴趣可以去官方文档上找寻，如果有什么不对的地方还请您指正，最后感谢您的阅读！