上一篇舉了一個小例子來說明，一般遇到比較冗長的 .gitlab-ci.yml 大致上可以怎麼思考整理及重構，那麼平常在規劃及設計流水線的時候該怎麼注意呢？

一、GitLab 怎麼談如何讓 YAML 變得更好？

在 GitLab 的部落格中，有一篇談論著怎麼讓 YAML 設定控制著的流水線(Pipelines)越來越好的文章，內容不難，提到了三個很實用的小技巧，首先是：

1. 讓工具幫忙格式化

YAML tip #1: Let other tools do the formatting for you

許多的文字編輯器或 IDE 像是 Atom、Sublime、VS Code等等，都有提供很不錯的 YAML 格式化工具，讓這些工具初步的排除格式上的問題，會幫忙省去很多對於 YAML 上除錯的時間，在正式上到 GitLab 進行測試前，也在透過 GitLab 的 CI lint 工具再次檢測，又會再省一些時間。

2. 讓它保持簡單

YAML tip #2: Keep it simple

讓工作流程的內容盡可能地保持簡單，在 GitLab CI 的設計中，參數幾乎都已經有預設值了，且這些預設值都是基於大部分的情境設定；因此，在編輯設計 .gitlab-ci.yml 的時候，如果確定預設值是可用的，就不要再設定一次，只讓工作的流程保留必要的設置，如此可以讓工作的內容更易於暸解。

3. 如果可以，重複的使用這些設定檔

YAML tip #3: Reuse config when possible

讓工作流程的內容可以儘可能地重複使用，在 GitLab CI 的設計中，提供了幾個方便重複使用的參數及語法，像是 Day 14 談的 anchor、Day 15 的 extends、Day 16 的 include 等，都是很適合用來重複使用時可以使用的語法。

另外，如果團隊裡，許多專案都可以套用相同的工作流程，也可以思考，直接將完整的 .gitlab-ci.yml 變成多專案可以共用的流程專案，其他專案透過參數的傳遞等技巧，並透過 Day 26 談及的 trigger 來做觸發啟動流水線。

二、多參考公開專案

重構 .gitlab-ci.yml 的內容，還有蠻多可以參考的方法，像 GitLab 官方 OpenSource 的專案中，就有許多很值得學習，在這邊推薦兩個，如：

• GitLab.org / gitlab-runner
  這是 GitLab Runner 的專案，他的 .gitlab-ci.yml 主檔裡頭，大量的使用了 include 的技巧，並透過載入的檔案的命名，可以充分的了解載入這個檔案的目的是什麼，對於初期接觸該專案的人，也可以透過這些命名，快速的找到自己該看的流水線工作內容。

• GitLab.org / Auto Devops v12.10
  GitLab 的 Auto Devops 是很好用的，他的 YAML 內容也是相當經典值得學習的好範例，其進入點有兩個，一個為：Auto-DevOps.gitlab-ci.yml，另一個是：Auto-DevOps-remote.gitlab-ci.yml 這兩份有一個共同的特色，它把 GitLab CI 的 workflow rules 利用到非常的極致。透過 workflow:rules 判斷存在什麼檔案，而後進行對應的工作流程。

  其他關於 rules 在 Day 10 的內容中有談論到，主要可以參考官方文件的 workkflow:rules。

三、總結：

這是屬於鐵人賽 30 篇文章的第 30 篇，這三十天讓自己重新的學了一次 GitLab CI 流程的設定，一來也是 GitLab 的更新速度很快，二來也是在寫文章的當下才又發現有些細節一直沒往下追究，是一個不錯的學習體驗。

手上其實還有一些排定，但後來暫時不寫的內容，主要是有些不是太常用，或判斷後覺得重要不沒那麼重要，所以先留著之後再繼續補齊，像是自動完成 GitLab Release 頁面、讓單一工作取得 code coverage、取得 submodule 內容的小技巧、 不用定義也存在的兩個 stage .pre 和 .post 等等。

我是墨嗓(陳佑竹)，期待這系列的文章能夠讓人有些幫助。

四、參考資料：

• 3 YAML tips for better pipelines | GitLab