Gitlab CI/CD 簡單介紹

| | 0 Comments| 13:42
Categories:

今年初,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 的紀錄吧~

Leave a Reply

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *