持续集成（CI）
持续集成用于将开发团队成员中的代码集成到公共仓库中。每当开发者进行类似于代码提交等操作的时候，便会执行安装依赖、编译代码、自动化测试等操作。
一个项目的持续集成工作如果采用纯手工操作通常会比较繁琐且容易出错，因而引入gitlab-ci来进行自动化的持续集成工作，每个开发者完成一部分的功能模块时便将其集成至主干之中，这样做能够更早地发现项目之中存在的一系列问题并加以解决，避免了以往在项目后期合并代码产生大量难以解决问题的情况。
基本原理及流程
首先要确保有一台部署了GitLab且版本在8.0以上的服务器，如果没有服务器，直接使用 https://gitlab.com 上的服务也可以。之后还需要另一台机器来安装gitlab-runner。
这个gitlab-runner是个什么东西呢？简单来说，它就是一个用来执行集成脚本的东西。比如说，当有人往仓库里push了代码，gitlab-ci就会找出和这个项目相关联的runner，并通知runner执行定义好的脚本。
具体如下图所示
流程图
一台机器上可以存在多个runner，runner也可以存在多个机器上，可以是开发服务器，可以是打包机，甚至也可以是你的本地电脑。
GitLab-Runner安装和注册
安装相关的文档在官网已经介绍了，可以去官网进行查看 https://docs.gitlab.com/runner/install/
这边发一下CentOS上的安装流程(其实也是摘抄自官网的)
# 下载源文件
sudo wget -O /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
# 赋予runner执行权限
sudo chmod +x /usr/local/bin/gitlab-runner
# 如果要使用docker，请先下载docker(这步可选）
curl -sSL https://get.docker.com/ | sh
# 创建一个gitlab-runner账号
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
# 安装并作为服务运行
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start
安装完成以后接下来演示注册一个gitlab-runner
sudo gitlab-runner register
接下来会让你输入相关的url、token等信息。
register需要输入的字段
这些信息在项目页的setting->CI/CD->runner那栏展开中可以看到。如下图所示：
注册需要的信息
之后会让你输入一个tag，这个字段要注意保存下，后续会和项目的配置文件中做关联。这边先命名为init-tag。
GitLab Runner中存在以下几种类型：
- Specific Runner，它只能供部分项目使用，用来支持一些特定的需求。
- Shared Runner，这种Runner 是所有 GitLab 中的项目都可以使用的。
- Group Runner，当你在一个Group下有多个项目，并且你希望这些项目都可以访问一组Runner时，它会很有用。
如果你在使用 https://gitlab.com 的服务，每个月可以获得2000分钟的Shared Runner构建使用时间。在用户的 Setting -> Pipelines quota 可以查看到已使用时间。对于个人或者小型企业来说，这个时间量基本是够用的。
时间
runner在执行构建任务的时候会有比较大的性能消耗，所以还是建议将其配置在专门的打包机上进行运行。
GitLab CI Pipeline相关的配置
在开始这节内容之前，先简单介绍一下pipeline、stage、job的概念。
job：最小的任务单元，通常只做一件事情，比如测试、编译。
stage：代表一个阶段，阶段中可以包含多个jobs，一旦有一个job出现错误，那么下一个stage将不再执行，只有全部jobs执行成功才会开始执行下一个stage。
pipeline：翻译过来是管道，你也可以把它当成一整个流水线，里面有多个stage有顺序地排序在一起。
整体结构可以看下图：
pipeline、stage、job的关系
图中的便是一个完整的pipeline，其中Update、Test、Build分别代表了三个阶段。每个阶段中都有自己的job，比如Test阶段中就有test-job1和test-job2两个job。
有了以上的铺垫，接下来我们可以来看看项目中的配置文件如何书写。
首先在每个你要管理项目中的根目录下添加一个.gitlab-ci.yml的文件。
.gitlab-ci.yml文件定义了Pipeline整体的结构以及顺序，并确定gitlab-runner要执行什么。
下面是最简单的示例
image: node:10.14.2
#有哪几个阶段要执行
stages:
- stage1
- stage2
stage1-job1:
# 这个job属于哪个阶段
stage: stage1
# 要执行的shell脚本
script:
- echo `pwd`
# 根据定义的标签选择对应Runner
tags:
- init-tag
stage1-job2:
stage: stage1
script:
- echo `pwd`
tags:
- init-tag
stage2-job:
stage: stage1
script:
- echo `pwd`
tags:
- init-tag
我们前面注册runner时存下的tag在这里就可以用上了
这样我们每次push代码到gitlab上以后，runner所在的机器就会自动执行里面的shell命令了。
配置文件的详细写法可以参考官网 https://docs.gitlab.com/ee/ci/yaml/
核心流程
最后总结一下大致的过程
- 首先注册
runner，输入url、token、tag等信息，注册时会向GitLab发送一个请求。 -
GitLab接收到请求后会返回一个token给runner，runner之后和GitLab的请求通讯都会带上这个token。 - 注册成功后
runner会向GitLab轮询请求，查看是否要执行任务。 - 某位开发者push了代码，代码更新了，这时候流水线
pipeline启动，并将第一个stage设置为pending状态。 - 在步骤4完成没多久，
runner的下一次请求已经到达了，这时候会把pending状态的stage发送到runner处，之后runner开始干活，执行gitlab-ci.yml中的脚本。 - 当执行完了脚本后，
runner会发送最终的执行结果，如果完成则为passed，失败则为failed
网友评论