在正式開始談 GitLab CI 前，首先必須要先知道 GitLab 與 GitLab CI 及 GitLab runner 之間的關係。GitLab 提供團隊建立從原始碼更新到 GIT Repo 之後的工作流程 (Workflow)以及在工作流程中建立工作流水線(Pipeline)，其中包含一道一道的關卡(Stage)與每個關卡中的工作(Job)。如官方所提供的架構圖：

一般團隊的在完成原始碼的修訂，正式發布 push 到 GitLab 上之後，可能還需要作一些原始碼的測試及原始碼的部署，就如圖中所定義的流水線包含兩大部分，分別是 CI (Continuous Integration, 持續整合) PIPELINE，在這部分，對於 GitLab CI 來說，我們可以想像他就是一個包含 Build、Unit Test、Integration Tests 等工作的「關卡, Stage」；而 CD（Continuous Delivery, 持續部署）PIPELINE 的這個關卡，則有 Review、Staging、Production 三個工作。

而圖片中提到的這些關卡及工作，在 GitLab 這個系統中，都可以透過 .gitlab-ci.yml 來定義，把流水線中需要的關卡、工作等先後順序、要做哪些事情等，都定義在其中。透過原始碼的修訂，正式發布到 Git Repo 之後，在 GitLab 看到有 .gitlab-ci.yml 後，依照 .gitlab-ci.yml 定義的工作流程流水線建立起對應的工作。那麼，這些工作誰作呢？

GitLab Server 與 GitLab CI Runner 的關係

.gitlab-ci.yml 檔案定義了流水線(Pipeline)、關卡(Stage)與工作(Job)，並透過 GitLab Server 依據流水線的定義，建立起工作，但這些工作由誰來作呢？在 GitLab CI 的生態系裡，所謂的「GitLab Runner」就是這些負責把工作作掉的夥伴。

如 GitLab 上圖 官方所提供的 Runner Server 與 GitLab Server 的關係圖可以看出，GitLab Server 可以對應到多個不一樣的 Runner Server，Runner Server 上可以執行多個 Runner；而可以執行 Runner Service 的平台則是相當的多元 ，如 Linux、Docker、macOS、Kubernetes(K8S)甚至是 Windows 等等。

只是必須要注意，執行 Runner 的環境，必須可以讓 Runner 透過 GitLab API 網路連線到 GitLab Server 上，因為，當 GitLab Server 建立幾工作等待 Runner 來執行時，是 GitLab Runner 們，在手上沒工作作的時候，去詢問 GitLab Server 有沒有「符合」它可以作的事情，符合之後，才取下來作，並且，工作期間及工作完成無論成功或失敗，都主動的回報工作狀況給 GitLab Server。

接下來在明天，我們將談談 .gitlab-ci.yml 怎麼去定義這些關卡、工作。我是墨嗓(陳佑竹)，期待這系列的文章能夠讓人有些幫助。