同樣舉昨天提過的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：

每一次的自動化都是他在幫我們跑Script和Git 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組成後遇到的下一個問題。