iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 9
0
自我挑戰組

Re : 從懶開始的自動化生活系列 第 9

[D9] : 關於我怎麼理解CI的運作

同樣舉昨天提過的Build 和 Test為例。

CI定義

來自於我隨便找的一段 RedHat - What is CI/CD? 提到

The "CI" in CI/CD always refers to continuous integration, which is an automation process for developers. Successful CI means new code changes to an app are regularly built, tested, and merged to a shared repository. It’s a solution to the problem of having too many branches of an app in development at once that might conflict with each other.

前半段很符合我現在的認知,CI是一個自動化處理流程,並且做Build、Test甚至是Merged這類常態性工作,講白就是自動化省時間、減少人工執行的失誤率。

CI,Continuous Integration又稱持續性整合,以前的我對CI就只會掛這句在嘴邊。
自從我開始接觸了Jenkins, GitLab, GitLab Runner, Yaml, Script, Docker...

因此我想趁這機會記錄下怎麼從只知道單字與縮寫和中文翻譯的我,變成隨時都能建一段Pipeline出來的我。

咱們以GitLab CI Pipeline為例,會有幾個角色參與一個CI的生態:

  • Runner
  • Script
  • Yaml
  • Git

Runner:

每一次的自動化都是他在幫我們跑ScriptGit fetch, push to artifact之類的操作。
所以也要意識到,Runner最好是一台伺服器,他需要不眠不休常駐的。

在我認知中我把它當成一個管家,24小時工作不停歇,交代給他的事情會幫我處理好,有問題可以回報讓我知道。 題外話是Jenkins的Logo就是一個管家,Jenkins也是實作CI的一個選擇。

Script:

我們請到Runner了,得要告訴他們怎麼做每一件事情,Build該做什麼,Test該做什麼,這時就要寫Script,Script就是一種跟Runner對話的語言。如果你的Runner是Docker,那就得寫成它讀得懂的。
在你的runner/config.toml設定檔裡面,會提到這個Runner使用哪種執行終端。
下面這段設定檔中提及他使用Shell,我們寫的Script得確保能在Shell上面可以運作。

[[runners]]
  name = "shell executor runner"
  executor = "shell"
  shell = "powershell"

另一個例子Executor是Docker的話,則可以參照這個官方頁面的表格。

由於我主要還是在Shell上操作,也沒用過docker-windows,所以以我過去淺淺的經驗來說,Linux system的終端可以跑的動的指令我就可以寫成Script給Executor是docker的runner跑。

Yaml:

Script要寫在一個叫做.gitlab-ci.yml的Yaml檔上,它是Runner的工作說明書,GitLab平台偵測到專案底下有這個名字的檔案的話,就會啟用PipeLine,嘗試跑上面的指令。

Git :

假設今天Runner要做Build,那麼他哪來的專案??,因此這位Runner,需要能夠從GitLab上Fetch你的專案下來。講簡單點是,要能夠Access到GitLab上你要處理的那個專案。


:::success
每一次Commit Psuh提交,都會觸發GitLab去執行.gitlab-ci.yml檔裡面的指令,指令中提到要找哪一位Runner來做事,該做什麼事請參照檔案中Script欄位提及的內容。
:::

以上這是我對CI的了解思路,希望有幫助到也剛開始了解CI/CD的人。

下次我們來講Yaml File怎麼寫,這是我在搞懂CI組成後遇到的下一個問題。


上一篇
[D8] : 利用GitLab CI達成減少Build與Test的成本
下一篇
[D10] : Yaml File on GitLab CI
系列文
Re : 從懶開始的自動化生活30

尚未有邦友留言

立即登入留言