什么是CI/CD？基本的gitlab CI/CD流程详解

CI/CD原理、yaml语法、.gitlab-ci.yml配置、runner流程等文章也许你已经看了不少，但是还没实际操作过的同学相信也很多。下面带你实际操作一把CI/CD，串一串学过的知识点。

什么是CI/CD

通俗来说就是启动一个服务，能够监听代码变化，然后自动执行打包，发布等流程；

拿最简单的静态页项目部署流程举例：首先需要手动npm run build后，再将dist文件夹通过工具上传到服务器的某个目录下，再启动配置好的nginx等服务器程序；有时为了调试，不得不频繁发布测试......

“懒是促进技术进步的原动力”

如果我们修改代码后，能够自动完成后续的那一堆任务那该多好，CI/CD的概念发展了起来。

可见要实现自动化，我们最起码需要两个关键步骤：

1. 监听代码变化；

2. 执行后续的各种任务；

而gitlab为我们提供了现成的工具gitlab-runner，能够帮助我们实现上面所述的步骤；我们只需要按照官方说明，在自己的服务器上安装gitlab-runner，并在项目仓库里注册其相应的信息即可。

gitlab-runner的主要作用

1. 监听来自gitlab的各种消息（如：代码push）；

2. 执行.gitlab-ci.yml文件（GitLab CI/CD的配置文件）中的任务；

如何自动化构建、自动化测试、自动化部署？那都是.gitlab-ci.yml中的Job，后面会介绍。

也就是说，自动化流程都可以通过.gitlab-ci.yml中的Job的Shell指令来实现。下面进入正题，我们先来搭建CI/CD所需的环境。

搭建gitlab CI/CD

1. 创建gitlab仓库

首先创建一个gitlab仓库（本示例里叫做testCI，是用vue-cli创建的一个朴实无华的项目）。进入项目后看到界面如下：

打开左侧菜单Settings > CI/CD项，可以看到Runners项，点击右侧按钮Expand:

gitlab CI/CD需要我们自己的服务端启动gitlab-runner，而gitlab-runner启动后得到的服务进程就叫做Runner；每个gitlab项目都可以绑定多个Runner。

下面创建Runner的索引，用来关联当前项目仓库与后面的**Runner**进程

2. 创建Runner索引

这里我们点击New project runner按钮去新建一个Runner索引，界面入下：

然后按照以下步骤操作：

1. 选择Runner服务器的操作系统

2. 创建Runner的tags，也可以勾选Run unstagged jobs（用途后面讲解）；

3. 点击创建按钮Create runner进入Runner注册指令页面：

到这里，需要在gitlab完成的操作已经结束，下面开始服务器端的配置流程。

对于只想试试看的同学可以在自己电脑上进行下面的操作，也就是把自己的电脑作为服务器。

3. 创建Runner服务

正如开头我们介绍过，我们的服务器要监听gitlab的push消息就需要安装gitlab-runner软件，启动后就创建了Runner服务。

可根据上图所示的官方链接，查看安装指令；下面是macOs系统的安装步骤。

1. 按照上图所示的指令安装gitlab-runner；含义如下所示：

sudocurl--output/usr/local/bin/gitlab-runnerhttps://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64


sudochmod+x/usr/local/bin/gitlab-runner


cd~


gitlab-runnerinstall


gitlab-runner start

当这5步执行完毕后，终端输入gitlab-runner status查看gitlab-runner运行状况:

Runner服务启动成功。

2. 执行Step1指令进行注册：

gitlab-runner register --url https:

该指令用于将当前的Runner注册到gitlab并与我们的前面创建的Runner索引信息绑定在一起。

输入该指令后会有3步交互式输入：

a. 设置gitlab地址；直接点击回车即可。

b. 设置Runner的名字；随便写，这里是test-ci

c. 设置Runner的执行器类型；这里选择shell类型。

最终效果如下图所示，这就完成了Step2：

3. 执行Step3指令:gitlab-runner run，可以看到终端显示如下：

到这里，gitlab CI所需的环境算是搭建完成了！

回到gitlab开始的CI/CD页面，就可以看到新建的Runner服务可以使用了。

4. 编写.gitlab-ci.yml文件（后续补一篇配置项解析文章）

Runner会读取项目根目录下的.gitlab-ci.yml文件，执行其中的任务，我们在项目根目录下添加.gitlab-ci.yml文件：

内容如下：

stages:
  - dev
  - test


测试dev:
  stage: dev
  tags:
     - test
  script:
    - npm i
    - npm run dev


测试test:
  stage: test
  tags:
     - test
  script:
    - echo "Running test..."

这里规定了两个任务阶段：dev与test，同时创建了两个Job：测试dev与测试test，并将测试dev挂载在了dev阶段，将测试test挂载在了test阶段；

这两个Job要注意tags需要与gitlab上创建的Runner索引的tags相同，不然不会执行！

5. push代码试一下

将代码修改push到git仓库，就能看到Runner终端有反馈了！同时可以看一下gitlab仓库的Pipelines页面：

可以看到dev阶段正在执行中(上图所示的“状态图标”为“进行中”)。

如果任务一直处于等待状态，可能是gitlab访问不到本地Runner服务的IP地址，或者网络有问题，如图：

可以点击“状态图标”看下日志页面：

发现npm run dev熟悉的输出，可以在服务端（这里是本地开发环境）打开该链接看一下：

最终，我们成功利用gitlab CI的能力，运行了本地的npm run dev命令......

总结

到这里，其实主要目的已经达到了：

1. 我们成功搭建了gitlab CI/CD所需的环境；

2. 实现了服务端监听git的push行为；

3. 服务端Runner执行了.gitlab-ci.yml文件上的Job。

若要实现更复杂的流程，只需要完善.gitlab-ci.yml文件中的配置。

后续改进

上面我们搭建了gitlab CI/CD所需的环境，并成功执行了本地的npm run dev。由于npm run dev指令是持续性的任务，导致测试dev是无法完成的Job，进而导致dev阶段一直处于运行状态，而test阶段无法开始；我们修改下配置（npm run dev -> npm run build）：

stages:
  - dev
  - test


测试dev:
  stage: dev
  tags:
     - test
  script:
    - npm i
    - npm run build 
    - pwd 
    - ls 
测试test:
  stage: test
  tags:
     - test
  script:
    - echo "Running test..."

最终运行结果如图：

全部Job顺利执行完毕：

这样我们就完成了基本的CI/CD流程的创建，如果还需要deploy、test等后续功能，只需要继续完善.gitlab-ci.yml 文件，例如：通过shell命令将dist移动到想要的位置，启动nginx等；或者通过执行*.sh文件来完成更复杂的操作。

结束

gitlab CI/CD大致的工作流程：

1. 我们将修改的代码push到gitlab仓库；

2. gitlab将push消息发送到我们的服务器，服务器Runner接收到消息；

3. 服务器Runner将仓库代码pull下来，按照.gitlab-ci.yml 文件执行Job；

4. 服务器Runner将构建信息（例如测试报告，终端输出等）上传到 GitLab 。

GitLab 服务器根据 Runner执行结果，更新项目的 CI/CD 状态和日志，并通知相关的用户或团队。

6.如果.gitlab-ci.yml 文件不增加其他配置（如：artifacts字段等），Runner将在执行完Job后清理构建产物（如dist文件夹）；

通过上面的演示，我们完成了一个前端项目最基本的gitlab CI/CD流程，功能很简单，但是相信没上手实践过的同学对其基本原理与流程能有一定的了解，今后在看相关文章时也能有一个基本的概念（版权归掘金硬毛巾原作者所有，侵删）

审核编辑：黄飞