GitLab-CI持续集成（CI）的介绍与运行机制

 GitLab持续集成（CI）的介绍与运行机制

GitLab-CI

GitLab-CI就是一套配合GitLab使用的持续集成系统（当然，还有其它的持续集成系统，同样可以配合GitLab使用，比如Jenkins）。而且GitLab8.0以后的版本是默认集成了GitLab-CI并且默认启用的。

首先要明白它的组成. 它有两个东西来支撑:

gitlab-ci server

gitlab-ci-runner

gitlab-ci server负责调度、触发Runner,以及获取返回结果.

而gitlab-ci-runner则是主要负责来跑自动化CI的一个宿主机子.

那么我们总结一下流程,其实是这个样子的:

 

GitLab-Runner

在GitLab 8.0+提供了持续集成的功能，在GitLab中有个Runners的概念。runner可以想象成一个守护进程,来守护你注册好的service和gitlab-ci绑定. 一个宿主机里的runner可以维护多个不同的service. 而gitlab-ci在收到需要build的请求时,会通知service执行你在.gitlab-ci.yml里面指定好的脚本,然后根据命令行的返回结果来决定这次build的成功还是失败.

在了解完了这些概念以后我们就可以很轻松的搭建一个runner了.

 
Runner一共有三种类型

1) 本地Runner

2) 普通的服务器上的Runner

3) 基于Docker的Runner

Runner可以分布在不同的主机上，同一个主机上也可以有多个Runner。

Runner类型

GitLab-Runner可以分类两种类型：Shared Runner（共享型）和Specific Runner（指定型）。

Shared Runner：这种Runner（工人）是所有工程都能够用的。只有系统管理员能够创建Shared Runner。

Specific Runner：这种Runner（工人）只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。

 

GitLab-CI与GitLab-Runner的关系示意图

 
那GitLab-Runner又是什么东东呢？与GitLab-CI有什么关系呢？

GitLab-Runner是配合GitLab-CI进行使用的。一般地，GitLab里面的每一个工程都会定义一个属于这个工程的软件集成脚本，用来自动化地完成一些软件
ba34
集成工作。当这个工程的仓库代码发生变动时，比如有人push了代码，GitLab就会将这个变动通知GitLab-CI。这时GitLab-CI会找出与这个工程相关联的Runner，并通知这些Runner把代码更新到本地并执行预定义好的执行脚本。

所以，GitLab-Runner就是一个用来执行软件集成脚本的东西。你可以想象一下：Runner就像一个个的工人，而GitLab-CI就是这些工人的一个管理中心，所有工人都要在GitLab-CI里面登记注册，并且表明自己是为哪个工程服务的。当相应的工程发生变化时，GitLab-CI就会通知相应的工人执行软件集成脚本。如下图所示：



 

 

GitLab CI-CD流程图