本文為系列文章《跟著 GitLab Auto DevOps 學習 CI/CD Pipeline》的第二篇，藉由逐一檢視並解析 GitLab Auto DevOps 背後的 Templates，讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。
在上一篇文章，我們了解 Auto DevOps 可說是 GitLab CI 的火力展示，它以 Auto-DevOps.gitlab-ci.yml 為起點，利用 include: 引用了多個 Template，構成了可以自動產生 Pipeline 的 Auto DevOps 功能。本文我們將延續上一篇文章，從 Auto-DevOps.gitlab-ci.yml 繼續認識官方是怎麼規劃與管理 pipeline 與 templates。
此系列文清單：
跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（一） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（二） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（三） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（四） 結構 善用 include: 在上一篇文章，雖然我們只是快速的解釋 Auto-DevOps....
自從 GitLab 推出 Auto DevOps 功能之後，我在許多演講與社群的場合都曾分享過，其實 Auto DevOps 並不是真的那麼「Auto」，它的背後是仰賴 GitLab 官方事先預備好的眾多 GitLab CI Templates，這些 Templates 能夠根據 Project 內容，自動產生多種情境的 CI/CD Pipeline。因此如果你想要自學 GitLab CI 的各種進階用法與技巧，或想要參考別人如何規劃 CI/CD Pipeline，那麼這些建構出 Auto DevOps 的諸多 CI Templates 即是我們絕佳的學習與參考對象。
既然 GitLab 官方準備了這麼好的學習材料，當然要好好運用它，因此從本文開始，接下來我將以系列文的方式，逐一檢視並解析 GitLab Auto DevOps 背後的 Templates，讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。
此系列文清單：
跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（一） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（二） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（三） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（四） Auto DevOps CI Templates 首先讓我們快速查看 GitLab 官方準備的 Auto DevOps CI Templates，如下網址，我們可以在官方公開的 GitLab Project 中找到它們。...
在 2021 年四月的文章中，我分享了透過 GitLab CI + JMeter 進行小規模 Load Testing；而在 2021 年七月的文章中，我則是試用了 Drill 這個新興的 Load Testing 工具。
承襲這兩次的經驗，在本文我們就以 GitLab CI + Drill，試一試「如何透過 GitLab CI + Drill 進行小規模 Load Testing」。
（本文同步發表於 Medium。）
操作步驟 首先我們要準備合適的 GitLab CI 環境，老樣子會需要一個可以操控 Container 的 GitLab Runner。如果你只是打算先試玩看看，那最簡單的方式就是使用 gitlab.com 以及官方提供的 Shared runners。
【小提醒】再次提醒大家 gitlab.com 的 Free plan 現在只有 400 CI/CD minutes per month。而且由於一直都有人在濫用這些免費資源，因此官方也有在評估該如何規範濫用的狀況。假如你真的想要由 GitLab CI 觸發 Load Testing，最好還是使用自己架設的 GitLab Runner 喔！
準備 Docker image - drill 接著準備合適的 Docker image。這邊一樣偷懶，就不追求容器 size 最小化，用最直白的方式建立一個可以在 GitLab CI 中使用的 Docker image - drill。...
先前在擔任講師時，有時會遇見學員反應「我的 GitLab CI 沒有在運作」，出狀況的原因當然很多種，像是 .gitlab-ci.yml 的格式錯誤、內容錯誤、Runner 設定錯誤⋯⋯，本文就來條列一些常見的原因。
（本文同步發表於 Medium。）
常見狀況 以下逐一分享幾種常見的異常狀況。
一、CI/CD Pipeline 設定檔的檔名錯誤 GitLab 預設的 CI/CD Pipeline 設定檔為 .gitlab-ci.yml，要注意前面有一個 .，以及是 yaml 檔案 .yml，不要太順手寫成 .yaml。另外就是 GitLab 也能設定改用別的檔名作為 CI/CD Pipeline 的設定檔，因此也要注意是不是有啟用這項設定，搞不好你的專案還真的已經改用 gitlab.yaml 當作 CI/CD Pipeline 設定檔了喔～
二、CI/CD Pipeline 設定檔的存放位置錯誤 續上，除了檔名之外，CI/CD Pipeline 設定檔的存放位置也很重要。預設的存放位置是專案的根目錄，存放位置也同樣可以自行修改。
【小提醒】CI/CD Pipeline 設定檔的檔名及存放位置都可以在 GitLab 的 Porject > Settings > CI/CD > General pipelines > CI/CD configuration file 中修改。
三、忘了啟用 Runner CI/CD Pipeline 要能運作，你必須要為 Project 啟用 GitLab Runner 才行。在 Porject > Settings > CI/CD > Runner 中確認是否有 Enable 任何一台 Specific runner 給此專案使用。...
本文將說明如何透過 GitLab CI + JMeter 實現小規模的 Load testing。
（本文同步發表於 Medium。）
操作步驟 先準備一個能夠操控 Container 的 GitLab Runner，gitlab.com 的使用者可直接用官方提供的 Shared runners。
站在巨人的肩膀上，我們要借用 justb4/docker-jmeter 這個優秀的 GitHub 專案，用它作為基底。
【補充說明】justb4/docker-jmeter 的作者已經寫好一個立即可用的 Test Plan 並搭配變數和幾個 script，也有易讀易懂的文件。因此如果你只是想要立即使用 JMeter 執行小規模的 Load testing，它只需要稍微微調就可以直接在 local 環境中拿來運用。
先將此專案 import 至 GitLab。由於是公開的 GitHub 專案，所以 Import project from 我們直接選擇 Repo by URL 並填入 GitHub 的 Git repository URL 即可順利 Import。 （等待 Import 動作執行完畢。）
由於 justb4/docker-jmeter 是設計用來直接拿來使用的，因此我們要稍作微調，讓它變成適合我們放在 GitLab CI 的模樣。調整的方向有 2 個：
修改 Test Plan，讓我們可以用 Variables 動態調整更多的 Load testing 參數。 讓 Variables 可以透過 GitLab CI 的各種方式輸入，方便以各種測試參數進行 Load testing。 決定好方向之後，開始實施客製作業。首先修改 Test Plan (....
在先前的文章，艦長曾說到 GitLab CI 的一項缺點，即是我們無法輕易的在 Local 環境運行 GitLab CI，往往需要反覆修改 .gitlab-ci.yml、送出 Commit 並等待 CI Pipeline 顯示出執行結果。這冗長又反覆的過程實在是為規劃 CI Pipeline 及撰寫 CI Job 帶來困擾，也大幅拖慢針對 CI Pipeline 本身的測試與驗證速度。
然而，這項長久困擾 GitLab 使用者的困擾，似乎浮現了一線曙光！為我們帶來希望的即是名為 glci 的工具。
（本文同步發表於 Medium。）
TL;DR glci 目前還在 v0.4.3，尚未進入 v1.0，是個 2021/2/17 才開始沒多久時間的年輕工具。因此尚無法在 Local 完整的還原 GitLab CI 的所有功能與行為。
但我必須說，能在 Local 執行 .gitlab-ci.yml 中的 CI Pipeline 與 CI Job 實在是很有吸引力的一件事，希望 glci 能持續發展下去，有興趣的朋友除了試用之外，不妨也考慮考慮發揮一下開源精神為此工具貢獻己力吧！
試用記錄 以下僅記錄這次試用過程的各項操作。
根據 README 的簡短註記，glci 可透過 yarn 安裝，所以先在 mac 安裝 yarn。
# macOS 使用 Homebrew 安裝是最省力的
brew install yarn 接著用 yarn 安裝 glci...
使用者在初次踏進 GitLab CI 的世界時，通常按著官方文件一步步照做，多半不會遇到什麼問題。唯獨有一項東西有可能讓新手產生較大的疑惑，那就是該如何選擇 Executor。
目前在官方文件上已經有提供了一份 Compatibility chart 幫助使用者選擇 Executor。本文就讓艦長也針對 Executor 表達一些看法吧！
（本文同步發表於 Medium。）
GitLab Runner 與 Executor 的關係 首先，讓我們先來解釋 GitLab、GitLab Runner 與 Executor 的關係。
讓我們拆開來說明，先從 GitLab 與 GitLab Runner 的關係開始。
如上圖，我們都知道 GitLab Runner 是用來幫助我們執行 CI Job 的工人，而 GitLab 就是這些工人的老闆。老闆（GitLab）會去查看需求單（.gitlab-ci.yml）建立一張又一張有先後順序的工單（CI Pipeline），而每一位工人（Runner）則是每隔固定的時間就去詢問老闆（GitLab）現在有分配給自己的工作（CI Job）嗎？現在自己應該做哪一項工作？工人拿到工作後開始執行，並且在執行過程中將處理進度即時填寫在工單上。
到這裡為止，大部分的人都不太會有什麼問題，讓我們接著說明 GitLab Runner 與 Executor 的關係。
前面我們將 GitLab 與 GitLab Runner 比喻為老闆與工人，那麼 Executor 是什麼？是工人的工具嗎？艦長覺得與其說是「工具」，Executor 反倒更像是工人的「完成工作的方式」或「工作的環境」。
舉例來說，就像我們都曾聽過的都市傳說，據說在國外有某知名企業的工程師，偷偷將自己的程式開發工作遠距外包給印度工程師完成，藉此實現上班摸魚打混還能取得高績效表揚的神奇故事。當然偷偷把正職工作私下外包是不正確的行為，但在這個故事中，這就是這位工程師「完成工作的方式」；同理用嘴巴命令別人做事、自己苦力的土法煉鋼、善用自動化工具或高科技工具輔助、遠距連線工作⋯⋯這些都是不同的「完成工作的方式」。
按著上面的比喻，依據你選擇的 Executor 決定了 Runner 將會採用何種「方式」及在哪個「工作環境」來完成 CI Job。
因此我們可以明白，這意味著身為老闆的我們，很可能需要聘雇多位不一樣的工人。舉例來說，炒菜煮飯這種工作，我們就會安排給在廚房工作的廚師、闖入民宅開寶箱這種工作，我們就會安排給 RPG 遊戲中的勇者。根據不同的 CI Job，我們有可能需要準備設置了不同 Executor 的 Runner 來因應。...