使用持續整合應該是一個軟體開發工程師的自覺。 ——沃茲基.索德

前言

在實際工作中，為了防止當前分支大幅度偏離主幹，開發人員每天都會頻繁地將程式碼整合到主幹。如果不使用持續整合，人工重複進行編譯部署等工作，無疑是低效且易出錯的。所以持續整合的優點顯而易見：

1. 減少人工編譯部署過程中的低階錯誤
2. 縮短開發週期，快速進行版本迭代
3. 隨時可部署
4. 讓開發人員專心coding（高效）

目錄

• 為什麼要用GitLab CI/CD
• 一點理論
• 一點實踐
• 一點問題

為什麼要用GitLab CI/CD

GitLab8.0之後，GitLab CI就已經整合在GitLab裡了。使用GitLab CI可以說是非常的簡單方便，先看下預覽圖

作者之前也嘗試了Jenkins。Jenkins作為老牌的持續整合框架，在這麼多年的發展中，積累很多優秀的外掛工具，不可否認它具有很多GitLab CI不具備的功能，但是Jenkins的使用複雜度跟GitLab CI 相比還是高了不止一點（不信往下看）。而且我覺得Jenkins的頁面設計太out。如果你跟我一樣是個初學者，還是建議你從GitLab CI開始嘗試。

一點理論

在實踐之前我們先介紹一些GitLab CI的相關概念。

pipeline

每次程式碼提交就會觸發一次pipeline。一次pipeline可以看成一次構建任務。構建任務一般會包含：安裝依賴，測試，編譯，部署服務等多個階段。

stage

stage就是上述構建任務中的各個構建階段。一個pipeline可以定義多個stage。stage有以下特點：

1.所有的stage按順序執行，前一個stage完成後，下一個stage才會開始執行。

2.只有當所有的stage都完成後，該構建任務(pipeline)才會成功。

3.如果一個stage失敗，那麼下一個stage不會執行，該構建任務(pipeline)失敗。

job

job表示構建工作，是每個stage構建階段裡具體執行的工作。跟pipeline與stage的關係類似，stage與job也是一對多的關係，即一個stage裡可以定義多個job，而job具有以下特點：

1.同一個 stage 中的 jobs 會並行執行

2.同一個 stage 中的 jobs 都執行成功時，該 stage 才會成功

3.如果任何一個 job 失敗，那麼該 stage 失敗，即該構建任務 (pipeline) 失敗

GitLab runner

在瞭解了上面幾個主要概念之後，我們對GitLab CI的工作流程應該大致已經清晰了，即下圖：

但是還有一個疑問就是：誰去統籌做上面一系列的事情呢？就是GitLab runner。

工作流程

綜合上述理論，要使用GitLab CI，我們首先要在專案的根目錄下新增一個 .gitlab-ci.yml 檔案，用來定義我們的stages，jobs等一系列具體內容，好讓GitLab runner據此來完成它的工作。然後需要在伺服器（開發或生產環境）上，配置一個GitLab runner，好讓GitLab runner去統籌持續集中過程中的所有事。

一點實踐

作者在自己的GitLab上初始化了一個express專案作為例子，帶大家來實踐一下。

配置 .gitlab-ci.yml 檔案

Configuration of your jobs with .gitlab-ci.yml 這是官方文件。

我簡單配置下demo專案的.gitlab-ci.yml檔案：

作如下解釋：
GitLab runner 會根據這個檔案內容進行構建，不難看出整個構建工作分為兩個stage（階段），第一階段install_deps：安裝依賴包，而具體的job內容就是執行:npm install。 第二階段：啟動程式。每次程式碼提交，都會觸發這兩個構建工作。新增快取cache是因為每個job執行成功後，runner都會去刪除.gitignore中的檔案。

安裝GitLab runner

GitLab runner的安裝很簡單。installing-the-runner 官方文件

作者以Ubuntu為例:

1、新增GItLa官方庫

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

2、安裝runner

sudo apt-get install gitlab-runner

配置GitLab runner

這裡我們配置一個specific runner。至於shared runner 和 specific runner的區別，大家可以通過官方文件的介紹，自己去選擇，這裡不贅述了。Shared vs specific Runners

1、拿到token

在你的專案setting->CI/CD->Runners settings下面找到url和token。

2、進行配置

在伺服器上輸入以下命令來配置一個runner：

sudo gitlab-runner register

然後根據提示把資訊填完。（作者為了簡單方便演示。Please enter the executor ：選擇的shell。）

檢視效果

更改程式碼並提交，然後在專案的CI/CD-->pipelines選項裡直接可以看到構建狀態：如圖

一點問題

在上面的實踐中我遇到的一些坑：
1、npm命令找不到：
因為gitLab runner構建的時候是以runner身份操作伺服器的，解決方法是：通過link命令把npm連結到 /usr/local/bin/npm。

總結

如果你的程式碼倉庫使用的是GitLab，那麼你好像沒有什麼理由不使用GitLab CI。