一、 Gitlab-CI/CD使用場景

首先，公司使用Gitlab作為工作倉庫進行程式碼釋出及版本控制，Gitlab內建了CI/CD的工具，這些工具可以用於程式碼提交的同時完成映象構建、自動化測試、自動化部署等連續的工作：

• CI: Continuous Integration（持續整合）
• CD: Continuous Delivery（連續交付）
• CD: Continuous Deployment（持續部署）
  這裡暫時只討論CI持續整合部分的工作，我們常用CI來做一些自動化工作，這種自動化工作會執行在一臺集中的機器上，比如程式映象的打包，單元測試，部署等，它可以節省專案開發迭代過程中維護正確的程式碼所耗費的時間。

例比如CI中自動測試，在多人協同開發的過程中，可能會有頻繁的不同分支的程式碼推送更新，使用CI管道，可在程式碼釋出的同時觸發CI中定義的單元測試操作，以便於在開發早期發現錯誤，從而確保所有新程式碼的提交都不影響專案功能。

二、 瞭解Gitlab-CI/CD工作流

參考下圖先了解CI/CD的具體工作流和概念，黃色部分為主要涉及的概念，將在後文重點說明：

1. 你當前的程式碼庫託管在Gitlab上， 且已經為程式碼倉庫配置了gitlab-runner服務, 它是用來實際執行CI任務的伺服器；
2. 提交程式碼，且根目錄中包含一個名為.gitlab-ci.yml檔案，該檔案是用來指定構建、測試和部署流程、以及CI觸發條件的指令碼，其概念類似於docker-compose.yml檔案；
3. Gitlab檢測到.gitlab-ci.yml檔案，若當前提交符合檔案中指定的觸發條件，則會使用配置的gitlab-runner服務執行該指令碼進行測試等工作；
4. 若.gitlab-ci.yml中定義的某個自動化指令碼執行失敗，將判定為此次CI不通過，則需要提交者修復問題程式碼後重復提交，直至自動化CI通過。
5. 沒有問題的提交才能被專案負責人merge到主分支，進行後續的部署工作（此文暫不涉及CD自動化部署）

三、 如何編寫.gitlab-ci.yml檔案

.gitlab-ci.yml檔案中指定了CI的觸發條件、工作內容、工作流程，編寫和理解此檔案是CI實戰中最重要的一步，該檔案指定的任務內容總體構成了1個pipeline

.gitlab-ci.yml示例檔案及常用說明

Pipeline說明

一個.gitlab-ci.yml檔案觸發後會形成一個pipeline任務流由gitlab-runner來執行處理，pipeline中stage、job概念如下，需要按照專案實際情況定義不同stage和job， 自己繪製了一個流程示意圖幫助理解:

按1.所示在專案根目錄中編寫好yml檔案，

1. 首先綠色方框中定義了stage的階段順序，總共定義了3個階段，按順序依次命名為build、test、deploy；

2. 第一個藍色方框定義了build階段的一個job，該job僅在tags階段的分支提交時觸發，執行script中的指令碼，按照DockerfileCI檔案將專案打包為成名為img的映象，並推送到倉庫中，然後移除本地映象；

3. 第二個藍色方框定義了test階段的一個job，該job沒有限制觸發條件，將在每次提交時執行。

   • Image指定了該階段使用的基礎映象，該映象為本地手動提前建立並推送;
   • services指定了該階段依賴使用的服務，mongo和redis，該job執行時會初始化指定服務版本的容器，並分別暴露域名為mongo:27017、redis:6379，需要在配置檔案中提前配置好CI專用的配置檔案;
   • befor_script指定了在執行正式指令碼之前預先執行的命令，列印python版本資訊、將CI專用測試配置檔案置為專案讀取的配置檔案、執行測試資料初始化指令碼、npm構建前端部分;
   • script指定了正式指令碼執行命令，開始執行django的單元測試。

4. 其他gitlab-ci.yml檔案參考

   • CI/CD Example: https://docs.gitlab.com/ee/ci/examples/
   • Job Keyword: https://docs.gitlab.com/ee/ci/yaml/#job-keywords

四、 Gitlab-Runner介紹和使用

上面講了.gitlab.yml檔案如何編寫以及其中的job執行順序邏輯，那各個job實際的執行者是誰呢，答案就是gitlab-runner，一般來說gitlab-runner會和gitlab所在的伺服器進行隔離，因為一個任務的構建、往往會執行編譯、測試、釋出的過程，這個過程會消耗大量的系統資源。gitlab-runner幾乎可以安裝在任何的機器上，只要能和gitlab所在伺服器及docker倉庫伺服器進行通訊即可。

一般來說，gitlab上已由負責人配置好了gitlab-runner，我們只需要編寫好.gitlab.yml檔案提交程式碼即可觸發runner進行工作。但對於初學者來說，你可能想能不能在提交程式碼前在本地先執行.gitlab.yml檔案的job，本地除錯成功檢查沒有問題後再進行最終程式碼的提交，觸發服務端的CI流程。答案當然也是可以的。之前已經說了，.gitlab.yml檔案中定義的job其實是某個伺服器中的gitlab-runner在執行，那我們也可以在本地安裝好gitlab-runner手動的來執行本地.gitlab.yml中的job。

Gitlab-runner的安裝

你幾乎可以在任何機器上安裝gitlab-runner，這裡講一下mac上的安裝方式:

• mac安裝： brew install gitlab-runner

• 其他安裝參考：https://docs.gitlab.com/runner/install/

• gitlab-runner-helper安裝：docker pull gitlab-runner-helper

注：gitlab-runner需要依賴gitlab-runner-helper本地映象，最好提前pull到本地倉庫或者私有倉庫中。

使用gitlab-runner執行本地.gitlab.yml中定義的job

目前本地的gitlab-runner貌似只能一次執行一個指定的job，而不能自動完成yml檔案包含的pipeline的總流程，但作為本地測試也是足夠了。當然，本地必須啟動有docker服務，並且提前準備好了需要的基礎映象, job會基於基礎映象，將原生代碼置於一個新目錄中執行，本地runner時一般為生成容器中的/builds/projects0目錄。

1. 進入本地專案根目錄，即包含了.gitlab.yml的目錄
2. 執行gitlab-runner命令：
   gitlab-runner exec docker test_job --docker-pull-policy=never

3. 引數釋義
   • gitlab-runner exec docker 為固定命令寫法;
   • test_job為.gitlab.yml中定義的一個job;
   • --docker-pull-policy=never表示使用本地的docker映象而非網路倉庫

這樣很簡單的安裝和命令便能在本地執行一個gitlab-runner的測試了。

推送程式碼到gitlab分支

本地測試沒問題後便可放心的將程式碼推送至遠端分支了，如果當前是fork倉庫，則需要同時將程式碼推送至upstream觸發主倉庫的CI流程，CI通過後，後續才可將分支程式碼合併至master。

五、欄位詳解

更多詳解：https://blog.csdn.net/sinat_17775997/article/details/116068193

附錄（涉及的其他相關操作）

配置docker私有倉庫

由於CI流程會使用到我們自己打包的一些docker映象，映象的上傳和下載會依賴組內的私有倉庫，下面介紹如何配置docker的倉庫連線：

• 編輯deamon.json配置檔案
  Mac電腦可以直接通過docker應用， Preferences—>Docker Engine 直接編輯配置即可：
   

   

  增加insecure-registries和dns配置如下：

"insecure-registries": [
    "你的私有倉庫host解析地址"
],
  "dns": [
    "你的私有倉庫dns地址"
    ]