使用持續集成應該是一個軟件開發工程師的自覺。 ——沃茲基.索德
前言
在實際工作中，爲了防止當前分支大幅度偏離主幹，開發人員每天都會頻繁地將代碼集成到主幹。如果不使用持續集成，人工重複進行編譯部署等工作，無疑是低效且易出錯的。所以持續集成的優點顯而易見：
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。