在 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 API 為 Project 設定 GitLab Runner，如果是使用工具前都會查閱說明書的資深 GitLab 使用者，可以直接轉身離開喔（喂～哪有文章一開頭就把人趕走的～）
（本文撰寫時，使用的 GitLab 環境為 14.0。） （本文同步發表於 Medium。）
前情提要 之前在 GitLab Taipei User Group 中有一位苦主表示遇到了一個狀況，他必須要將指定的 GitLab Runner 分配給超過百個 Project 使用，想詢問有沒有比較簡單的方法？
一般來說如果有 Runner 需要同時供應給多個 Project 使用，通常會建議將 Runner 建立為 Group Runner。如此一來在相同 Group 內的所有 Project 皆能直接取用此 Runner，唯一的限制就是 Project 必須隸屬在相同的 Group。因此對於苦主來說，這個解法他會需要將超過百個 Project 全部搬家至 Group 內，因此不太適用。
另一個方案是，假如你是自架 GitLab Server，則可以透過 Admin 管理者，架設 Shared Runner，便能夠如同 gitlab.com 那樣，直接提供不限 User、Project 皆能任意使用的 Runner。當然要說缺點就是 Shared runner 預設是全開放給所有人皆能使用的 Runner，因此如果你又想要做出額外的權限控管，同樣又要另外想辦法。不幸的是印象中苦主似乎是使用 gitlab.com，GitLab 官方當然沒開放權限讓使用者自行在 gitlab.com 上架設 Shared runner。...
先前在擔任講師時，有時會遇見學員反應「我的 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 給此專案使用。...
最近看了一篇熱門文章《利用 Apps Script 讓 Google 表單回覆自動產出 Google 文件》，不看不知道，看了才知道原來 Google 有推出 Apps Script 這麼神奇好用的東西，透過它可以搭配 Google 的服務實現各種「辦公自動化」。
這麼有趣的服務，令人不禁想要天馬行空的運用它，究竟我們可以拿 Apps Script 做什麼事情呢？
（本文同步發佈於 Medium。）
如前面所述，在思考 Apps Script 可以拿來做什麼時，忽然想起前一陣子研究 Jira service management 所注意到的一個功能——Customer Portal。簡單來說 Customer Portal 就是一個面向使用者的單一窗口與入口，假設今天是 IT/MIS 部門在使用 Jira service management，那麼 IT 部門就可以利用 Customer Portal 建立一個給一般員工使用的「IT 問題回報表單」。假如員工有各種 IT 問題，就填寫該表單，IT 部門則會從 Jira service management 得到員工回報的問題資訊，根據資訊開立 Ticket 並分配給工程師處理。IT 部門除了可以從 Customer Portal 得到表單提供的資訊，甚至還能夠設定當員工填寫了表單的某些選項時，就直接觸發事先準備好的自動化腳本，直接自動處理某些 IT 問題。
（Jira service management 的 Customer Portal。）
Customer Portal 這麼棒的功能，真希望 GitLab 也能擁有，但很可惜目前只能自己打造。所以就讓我們參考上面那篇文章，利用 Google 表單 + Apps Script + GitLab 試著快速搭建一個陽春版的「IT 問題回報表單」。...
本文將說明如何透過 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 來因應。...