GitLab持續整合（CI）的介紹與執行機制

GitLab-CI

GitLab-CI就是一套配合GitLab使用的持續整合系統（當然，還有其它的持續整合系統，同樣可以配合GitLab使用，比如Jenkins）。而且GitLab8.0以後的版本是預設集成了GitLab-CI並且預設啟用的。

首先要明白它的組成. 它有兩個東西來支撐:

1. gitlab-ci server
2. 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) 普通的伺服器上的

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裡面的每一個工程都會定義一個屬於這個工程的軟體整合指令碼，用來自動化地完成一些軟體整合工作。當這個工程的倉庫程式碼發生變動時，比如有人push了程式碼，GitLab就會將這個變動通知GitLab-CI。這時GitLab-CI會找出與這個工程相關聯的Runner，並通知這些Runner把程式碼更新到本地並執行預定義好的執行指令碼。

所以，GitLab-Runner就是一個用來執行軟體整合指令碼的東西。你可以想象一下：Runner就像一個個的工人，而GitLab-CI就是這些工人的一個管理中心，所有工人都要在GitLab-CI裡面登記註冊，並且表明自己是為哪個工程服務的。當相應的工程發生變化時，GitLab-CI就會通知相應的工人執行軟體整合指令碼。如下圖所示：

GitLab CI-CD流程圖