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；含义如下所示：
sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
cd ~
gitlab-runner install
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流程，功能很简单，但是相信没上手实践过的同学对其基本原理与流程能有一定的了解，今后在看相关文章时也能有一个基本的概念（版权归掘金硬毛巾原作者所有，侵删）
