讓 GitLab CI 的工作流程的流水線加速，透過上一篇的大部分解有了思考流程上的脈絡，接下來要開始從每個階段中的工作細節去思考，應該怎麼讓整個流水線再次的加速。首先來談談，流水線加速的一些核心思考邏輯，流水線加速的三原則：

一、流水線加速三要素

要加速流水線的進行，基本可以以三個要素去考慮，分別是：工作少做點、事情做快點、做事的多一點，從流水線工作進行的每一個階段都可以從這三個角度思考，是不是可以針對這三個要素作點什麼？

1. 工作少做點

在流水線啟動之後，流水線上有哪些關卡、哪些工作基本就已經確定了，流水線要進行多久，就取決於流水線上有幾個關卡，每個關卡上有多少工作需要被完成。

因此需要進行的關卡、要被完成的工作少一點，對於流水線的進行速度，有著最直接的加速。

2. 事情作快點

流水線啟動後，該做多少工作已經決定，那接下來還能影響流水線進度的就剩下工作們被執行完成的速度了，因此就可以朝怎麼讓工作被更快的執行完成去思考。

3. 作事的多一點

在 GitLab CI 上，真正完成流水線上關卡的工作的是執行做的 GitLab Runner，有多少的 Runner 可以完成事情，工作佇列上的工作需要等待多久才能被取出執行，也攸關著流水線能不能更快完成。

接下來開始從每個節點思考，可以怎麼從流水線加速的三個要素來加速。

二、從 .gitlab-ci.yml 到 Job Queue 思考 怎麼加快？

.gitlab-ci.yml 是 GitLab CI 工作流程中，定義流水線上關卡及工作樣貌最重要的檔案，從派發角度的思考，一條流水線的啟動到完成流水線工作，最重要的是什麼？

1. 什麼工作先做比較好？

流水線的啟動到完成，期間，最重要不一定是把工作完成，自動化流水線的加入還必須可以及早發現問題，及早讓團隊針對工作內容作調整。因此早點讓有決定性的工作先被執行也是流水線工作順序安排的一個策略，如這些工作真的失敗了，早點失敗，流水線自然會快點執行完成。這時候可以思考，什麼工作先做比較好？

• 跑的快的工作：有些工作可以很快的執行完成，像是檢測當下被修改的原始碼格式、Code Style 是否符合，如不符合，後續關卡的工作根本不用作。
• 有決定性的工作：全系統的單元測試都需要執行且全數通過才能讓原始碼 commit 到 GIT 上，應該是很多團隊都遵守的規則之一，像這種有決定性的作就也很適合放在較前面的關卡中先執行，早點確認，也早點知道後續的關卡是否可以繼續。

2. 每個工作都該做嗎？

一個多人同時維護的專案上，流水線需要執行的工作可能相當多元，如前後端元件在同一專案上，則專案上則可能存在著前端與後端各自的測試程式。這時候便可以思考流水線上的每一個工作，真的都需要執行嗎？如，當只是前端的原始碼變更，則可以考慮後端的測試是否需要執行，反之亦然。

另外每個狀態下的流水線啟動，就都啟動所有的關卡，所有的工作嗎？這部分答案應該是否定的。有些工作只需要在正式版本釋出的時候需要執行，有些工作只需要在 Code Review 前提供檢核者判斷，有些工作也只需要在特定工作完成後，接續完成，這些，都是可以思考哪些工作該做的思考方向。

針對流水線工作設置執行條件可以參考：Day 08、Day 09、Day 10 這三篇的內容，主要都在談關於工作執行的條件設置。

3. 有沒有工作花太多時間在等待進入工作佇列？

一個關卡上可能同時存在著多個工作，但這些工作彼此之間沒有關係，卻因為在同一個關卡中而無法讓下一個關卡中與此工作相關的工作先開始執行，造成部分工作非必要的等待。有辦法讓後續相關聯的工作先開始執行嗎？在 Day 11 的內容中談到「DAG 有向無環圖」用到 needs 這個參數，就可以做到這件事情。

如上面的案例，當使用了有向無環圖的機制後，甚至會發生，其中一個工作已經完成了，還有一些工作還在很前面的關卡。

可以誇張的想像，當同一時期的一些產品已經釋出在販售了，卻還有同一時期的產品還在測試驗證，無法出場，如果一直都被卡著無法釋出，對於產品開發也是一種損耗。

三、從 Job Queue 到 Runner Server 取得工作思考 怎麼加快？

在工作佇列等待 Runner Server 的 Runner 來取得工作去執行的這段流程中，可以思考：

1. 可以取得工作的 Runner 夠嗎？

可以取得工作的 Runner 夠嗎？有些時候團隊中同類型的工作能夠執行的 Runner 數量是有限的，像是某些部署流程工作，可能只被限制在特定的環境中，當有頻繁的部署專案需求時，就可能發生待執行工作在等待能做事的 Runner 來完成部署工作。

這時候為了要加速流水線完成，就可以思考，是否增加這類型的 Runner 數量。

2. 可以有更多的 Runner 嗎？

有些工作只要可以啟動 Docker 就可以完成對應的工作，建立執行 Docker 的 Runner 在這兩年是相對簡單的，但是還是可能發生在工作佇列等待被執行的工作數量比可以啟動 Docker 來執行工作的 Runner 還多，造成工作佇列待執行工作排隊等待的情境。

這時候就該思考，怎麼讓這樣的 Runner 數量可以再增加，以加速流水線完成的速度。

3. Runner Server 可以同步執行 Runner 嗎？

在安裝 Runner Server 時，有一些參數是重要的，像是 concurrent，代表著 Runner Server 同時可以執行工作的 Runner 數量，這時候就必須要注意執行 Runner Server 是否如環境的特質設置了對等可負擔的同時執行數量，Runner Server 可以同時負擔的 Runner 增加了，可以工作的 Runner 自然也會增加。

總結

在一開始談到流水線加速的三要素，分別是：工作少做點、事情做快點、做事的多一點，其用來成為工作流程流水線加速的思考角度，用在管控關卡及工作被執行的 .gitlab-ci.yml 可以往怎麼讓工作少做點思考，用在工作佇列管理上，則可以用怎麼讓幫忙做事情的可以多一點思考。

接下來將繼續談談，怎麼讓事情可以做快一點，我是墨嗓(陳佑竹)，期待這系列的文章能夠讓人有些幫助。