使用GitLabCI持續集成

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

#前言

在實際工做中，爲了防止當前分支大幅度偏離主幹，開發人員天天都會頻繁地將代碼集成到主幹。若是不使用持續集成，人工重複進行編譯部署等工做，無疑是低效且易出錯的。因此持續集成的優勢顯而易見：

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

#目錄

• 爲何要用GitLab CI/CD
• 一點理論
• 實踐一下
• 一些問題

1、爲何要用GitLab CI/CD

GitLab8.0以後，GitLab CI就已經集成在GitLab裏了。使用GitLab CI能夠說是很是的簡單方便，先看下預覽圖

做者以前也嘗試了Jenkins。Jenkins做爲老牌的持續集成框架，在這麼多年的發展中，積累不少優秀的插件工具，不能否認它具備不少GitLab CI不具有的功能，可是Jenkins的使用複雜度跟GitLab CI 相比仍是高了不止一點（不信往下看）。並且我以爲Jenkins的頁面設計太out。若是你跟我同樣是個初學者，仍是建議你從GitLab CI開始嘗試。

##2、一點理論

在實踐以前咱們先介紹一些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爲例:

一、添加GItLa官方庫

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

二、安裝runner

sudo apt-get install gitlab-runner

###配置GitLab runner

這裏咱們配置一個specific runner。至於shared runner 和 specific runner的區別，你們能夠經過官方文檔的介紹，本身去選擇，這裏不贅述了。Shared vs specific Runners

一、拿到token

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

二、進行配置

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

sudo gitlab-runner register

而後根據提示把信息填完。（做者爲了簡單方便演示。Please enter the executor ：選擇的shell。）

查看效果

更改代碼並提交，而後在項目的CI/CD-->pipelines選項裏直接能夠看到構建狀態：如圖

一些問題

在上面的實踐中我遇到的一些坑： 一、npm命令找不到： 由於gitLab runner構建的時候是以runner身份操做服務器的，解決方法是：經過link命令把npm連接到 /usr/local/bin/npm。

#總結

若是你的代碼倉庫使用的是GitLab，那麼你好像沒有什麼理由不使用GitLab CI。