在專案過程中，透過 GitLab CI 建立流水線，讓研發過程中如編譯、測試、打包、部署等工作都得以順利的自動化，除了讓開發變得更有效率，也在無形之中，形成了保護專案的門神。提到效率的，會希望好還要更好，如果 GitLab CI 的流水線可以跑得更快一點，除了讓研發等待的時間少了，自然也會省下一些資源。

接下來的篇幅，將討論怎麼讓 GitLab CI 的流水線進行得更快一些，在正式開始討論之前，看到這篇文的朋友，可以稍微想一下，當一個 GitLab 上的工作流程流水線被啟動時，一直到整個流水線的工作結束，期間會有哪些動作呢？或者是，會有哪些地方必須工作呢？

底下將透過工作的拆解來初步了解流水線期間發生了什麼事情。

一、從 .gitlab-ci.yml 到工作佇列 (Queue)

當 GitLab CI 的流水線工作啟動之後，GitLab CI Server 端會解析 .gitlab-ci.yml 的描述，依據描述部署出一條流水線，在這時候，流水線上每道關卡、每到關卡上的規劃的每一個工作都已經確立好它們的位置了。

接下來 GitLab CI Server 會將已經可以被執行的工作，依序放到工作佇列(Queue)上，等待工作被執行，待等待被執行的工作們回報它們的工作狀況後，GitLab CI Server 才根據 .gitlab-ci.yml 的描述，決定後續關卡上等待被執行工作是否派送到工作佇列等待被執行。當然也有可能已經沒有下一關卡，則最後一個被執行完的工作所回報的工作成果，就是這條流水線執行的最終結果。

二、從工作佇列(Queue)到 GitLab Runner

當等待被執行的工作們被排入 GitLab CI 的工作佇列上之後，與目前的 GitLab CI Server 有合作關係的且空閒著的 GitLab Runner 們，就會依據自身的工作執行能力來工作佇列詢問，是否有適合自己可以執行的工作。

GitLab CI Server 在此，就擔任著工作媒合者的角色，把等待被執行的工作發包給宣稱自己適合執行該工作的 GitLab Runner 拿回去執行，並且等待這些 Runner 回報工作狀況及工作成果。

三、Runner 取得工作後怎麼作事情？

GitLab Runner 在取得可以執行的工作後，便會在自己可以管控的區域中開始依據自己的能力初始化執行工作的環境，接著依據取得的工作描述佈置工作環境，而後正式開始執行這個工作。

執行的過程中隨時跟 GitLab CI Server 回報目前的進度狀況，變且根據工作的描述產出工作成品，並交回 GitLab CI Server 上留存，除了交出的誠品外，GitLab Runner 自己也會根據工作描述上所說的，留下可以暫存的產物，待下次取得可以使用這份暫存的工作，再次取出來使用，待這些工作都完成後，正式回應 GitLab CI Server 工作完成。

當然期間可能會因為一些工作環境等因素而造成工作執行失敗，這部分也會回應給 GitLab CI Server 讓 Server 判斷後續的工作分派該如何進行。

四、打個比方

如上面的三個段落，大致上把 GitLab CI 開始啟動一個流水線，一直到流水線完成可能遇到的情境做了一次交代，但文字有點多，內容有點煩雜，所以這邊想了一個古代鏢局護鏢的劇情來比喻 GitLab CI 的流程。

這部分可以想像小說裡頭的鏢局護鏢劇情，GitLab CI 的工作們就像是「鏢」；業主心裡有些想法，就像是 .gitlab-ci.yml 定義著這個鏢該分幾次運送、每次運送多少「鏢」、要送到哪；承接工作的鏢局就像是 GitLab CI Server，根據業主的需求逐步的把「鏢」公開出來，等待有空的鏢師們護鏢。

而與鏢局有合作關係的鏢師們是懂的自己有幾兩重的，自然只會選擇承接的起的鏢來護。護「鏢」的過程可能很順利，也可能會遇到一些狀況，這些都會一一的跟鏢局回報，哪怕是用飛鴿傳書。

鏢局根據鏢師們的護鏢成果來決定是否啟動業主的下一階段護鏢行動，當其中有一次護鏢失敗，則可能會導致後續的工作都不能再執行，當然也可能可以繼續執行，端看業主當初與鏢局談的合約 (.gitlab-ci.yml)。

總結：

把 GitLab CI Server 與 GitLab Runner 間的工作流程再次的透過文字描述出來，是因為要讓流水線執行的更順暢，必須從工作的每個環節中去著手，去思考它的必要性？思考是不是還有機會更快？接下來也會再根據這些環節逐一去討論更多細節。

也希望最後一段的的鏢局劇情，可以讓這些文字有了一點有趣的想像，我是墨嗓(陳佑竹)，期待這系列的文章能夠讓人有些幫助。