今年初，Heresy 算是終於把工作地方的 GitLab 重新架設起來了。而後來好一段時間，Heresy 則都是在研究他的 CI/CD（Continuous Integration and Deployment）到底該怎麼做，目前也算終於弄到可以動了，所以就在這邊紀錄一下吧～
不過，這篇主要是先就 Heresy 理解的概念來寫，也希望沒有理解錯誤就是了。
首先，Gitlab 的 CI/CD（官網）做的事情，實際上就是讓 Gitlab 系統，可以在特定的時候（通常是 push、merge、或是自己排程），根據所撰寫的腳本，去進行程式碼的自動化建置、測試、甚至佈署。
下面的圖，就是官方提供的 GitLab CI/CD 的示意流程圖。
在這個架構下，開發者可以根據自己的需求、來撰寫腳本進行客製化的流程，讓許多工作可以自動完成。
而這樣做的好處是什麼呢？在 Heresy 這邊因為主要是進行傳統程式的開發，所以主要就是可以透過自動建置、測試，來及早發現程式碼有出現問題了～
如果能再搭配程式碼的靜態分析的話，理論上應該也是可以做到更好的程式碼品質管理的。
實際上，GitLab 也很重視這一部分的功能，從 10.0 開始就有引進了「Auto DevOps」的功能（官網），提供了自動的 CI/CD 功能；而到了 11.3，這項功能更是直接變成預設開啟了。
但是，實際上「Auto DevOps」的功能雖然是被預設開啟了，要能真正運作卻還是需要額外的資源（Kubernetes cluster）才可以，否則只會收到一堆錯誤通知；而他預設似乎是會去使用 Google 的 Google Kubernetes Engine（GKE、官網），這項服務基本上也是要錢的。
本來 Heresy 也有考慮要自己架設 Kubernetes cluster 來讓 Auto DevOps 可以動，但是考慮到 Heresy 對 Kubernetes 不熟、Auto DevOps 的功能似乎也很雜，再加上手邊資源也不算多，所以後來還是決定先放棄「Auto DevOps」了。
而如果沒有要使用 Auto DevOps 的話，個人也建議先到 GitLab 的系統區把它關閉（Admin Area、Settings、CI/CD），否則應該會常常收到建置不過的通知信，會很煩。
那在不使用 Auto DevOps 的狀況下，要怎麼設定讓專案可以有 CI/CD 呢？這邊分成兩個部分：
- 針對專案建立 Gitlab CI/CD 設定檔：.gitlab-ci.yml
- 架設用來建置程式的 GitLab Runner（視狀況而定，可能會需要多台電腦）
其中，.gitlab-ci.yml 這個檔案是要放在 Git repository 的跟目錄下，它裡面就是描述 GitLab Runner 要怎麼進行建置、測試等動作。他的撰寫方法，可以參考官方的文件。
而 GitLab Runner（官網）呢，基本上就是一個獨立的系統，透過網路和 GitLab Server 連線（甚至可以在 NAT 後面、不需要實體 IP），來執行 .gitlab-ci.yml 裡面定義的工作。
.gitlab-ci.yml
基本上，.gitlab-ci.yml 裡面是定義一個流程、稱為「pipeline」，他是每次要建置、測試時應該要跑完的完整步驟流程；而一個 pipeline 裡面可以切割成數個「stage」（階段，例如 build、test 這樣算兩個 stage），每個「stage」則可以有多個「job」（工作）。
在執行的時候，他會按照 stage 的順序執行，前一個 stage 完成後、才會執行下一個 stage；如果同一個 stage 裡面有多個 job 的話，這些 job 可能會被同時執行。
當一個 stage 的所有 job 都順利完成後，他才會去執行下一個 stage；如果其中有某些 job 失敗了，那就不會執行下一個 stage，pipeline 也會就此以失敗的狀態結束。
像下圖就是有「Build」和「Test」兩個 stage 的 pipeline。
而在「Build」這個 stage 裡面有「build-windows」和「build-linux」兩個 job，在「Test」這個 stage 裡面有「test-windows」和「test-linux」兩個 job。
上面左圖，是一切順利的狀況；上面右圖，則可以看到「build-linux」失敗了，所以所有「Test」都不會被執行。
GitLab Runner
由於 Runner 基本上是獨立的，所以他也可以根據需求，建立出不同平台的版本（Windows、Linux）、不同的環境（MSVC、g++ 4、g++ 5）；目前也可以使用實體機器、VM、docker，甚至是使用 Kubernetes 來做 auto-scale。
像在上面的例子裡面，Heresy 這邊實際上就是建立了兩個 VM 的 Runner，一個是跑 Windows、一個是跑 Ubuntu，個別承接對應系統的工作。
當要執行 .gitlab-ci.yml 定義的 pipeline 的時候，GitLab Server 會去找合適的 runner，把這個 job 丟給 runner 執行。
至於哪個 job 該用哪個 Runner 呢，則是使用「tag」來做區分。
在設定 runner 的時候，可以給多個 tag，來描述 runner 的環境、性質；而在 .gitlab-ci.yml 中，也可以針對個別的 job 指定要找有哪個 tag 的 runner 來執行。透過這樣的機制，就可以對系統環境做區分了。
此外，也可以針對 Runner 做設定，看是要全站共用、群組共用、或是專案共用；如果系統的使用者比較多的話，也可以透過這樣的設定來做 Runner 資源的隔離、控制。
當 Runner 收到 GitLab Server 指派工作的時候，他就會從 GitLab Server 上把程式碼複製過來（用 git），然後執行所交付的工作，並將紀錄、結果回報給 GitLab Server。
雖然 Runner 有很多種不同的架設方法、要設定不同的 executor（官網），但是最後都還是要靠命令提示字元這種沒有 IDE、GUI 的形式來進行建置、測試的。
而整個建置的過程、結果，也都會被記錄下來，可以從 GitLab 的網站上看到（類似下圖）。
如果 pipeline 在執行的過程失敗的話，除了可以從記錄裡面去看是什麼問題外，系統也會主動發通知信給 push 上來的人、或者負責的人，讓他們知道現在的程式碼是有問題的。
而 Runner 的系統，則是可以視需要做調整。對於小型專案來說，要使用的資源（硬碟、記憶體、計算能力）應該不會太重要，但是如果是大型專案，可能就需要用好一點的機器來跑了～像 Heresy 這邊在使用 g++ 平行編譯的話，就會導致拿來建置的虛擬機器記憶體不夠（已經給他 10GB 了…），導致整個系統沒反應…
概念上大致上應該就是這樣了。之後有機會，再來整理一下架設 GitLab Runner 和撰寫 .gitlab-ci.yml 的紀錄吧～