前言 （感謝敏捷三叔公贈送簽名書一本！）
2024 年底，一則 FB 訊息傳來，原來是「敏捷三叔公」柯仁傑又在寫書了，希望我能為他正在撰寫的書籍內容提供一些意見；對於這種能夠搶先預覽好書內容的要求，我當然是毫不思考立刻答應。
隨著時光來到的 2025 年四月，再次收到敏捷三叔公的 FB 訊息，沒想到這次是三叔公邀請我為他的書撰寫推薦序；對於這種殊榮，我當然更是義不容辭的立刻答應！
如果你也經常有在注意市面上的軟體測試及 DevOps 相關書籍，不曉得你是否與我有同樣的感受，覺得能找尋到的正體中文資源頗為有限，總是希望市面上能有多一本相關的好書。
如今 2025 年七月，我們終於等到這本由敏捷三叔公 David Ko 柯仁傑撰寫的《軟體測試修練指南：我獨自升級的實戰心法》正式出版上市。三叔公出品必屬佳作，相信這本書能為台灣補足更多關於軟體測試的正確知識與觀念，也能成為下一個敲門磚，讓台灣能有更多關於軟體工程、軟體測試、軟體品質、Agile、DevOps 的好書得以持續出版下去！
再次感謝敏捷三叔公 David 柯仁傑讓我有機會參與這本書的出版，這本書真的很厚，他想談的內容真的很多，我當時提供回饋意見時，還希望他能寫更多一點！
（跟 10 元一樣厚的書！）
總之，強烈推薦大家快點去買好書，既能補充知識，又能支持敏捷三叔公與出版社，一舉數得喔！ 購書連結：天瓏網路書店
下面附上我所寫的推薦序全文，這次撰寫的文字風格比較正經一些，反倒是三叔公自己取的書名「我獨自升級」有趣多了。
推薦序全文 再多來一本吧！我們需要更多軟體測試的優質好書！ 如果你也是投身於軟體領域的工作者，你多半也體驗過因為軟體出現Bug或品質不良而讓你頭痛的時刻。軟體品質是一個所有使用者都十分在意的軟體基本需求，但對於軟體開發團隊而言，「品質」卻是一個需要透過整體軟體開發生命週期疊加累積才能交付的成果。
面對「提升軟體品質」這個目標，通常我們總是會說「下次我們要好好的做測試」，然而偏偏軟體測試是一項我們都認同它超級重要，但卻難以找到方法，將其有效融入日常開發流程中的艱難技藝。我們真的需要更多優質的軟體測試學習資源，幫助我們可以從整體觀念架構認識軟體測試，知道它知易行難及易學難精之處。
柯仁傑，在台灣敏捷社群中被暱稱為「敏捷三叔公」，是我十分敬重的 Agile 與軟體測試領域的前輩。他在台灣敏捷社群及軟體測試領域深耕多年，擁有扎實的軟體測試經驗。在這本《軟體測試修練指南》書中，他將自身累積數十年的軟體測試經驗轉化為有系統與架構的文字，涵括軟體測試基礎、方法論、到測試管理及人才培育多個主題，為我們提供了一份難得的學習指引。
你也是一位正打算加強軟體測試能力的工程師嗎？又或者，你是一位希望幫助團隊更落實軟體測試的倡議者？那麼，一起來閱讀本書吧！透過敏捷三叔公的視角，幫助你理解軟體測試在實踐中可能遇到的挑戰與應對之道，讓這本書為你的軟體測試學習之路，增添一份助力！
DevOps Taiwan Community 志工 & DevOpsDays Taipei Co-organizer 陳正瑋（艦長）
Every year, iThome hosts a challenge where IT practitioners write a blog post every day for 30 days. (iThome is a well-known IT news media in Taiwan.)
This year, I decided to join this challenge and chose a frequently asked question: ‘Why do you pay for GitLab?’ as my topic.
You can find all 30 posts on iThome’s website. If you’re interested, feel free to check out the links below....
前言 每一年 iThome 都會舉辦「iT邦幫忙鐵人賽」——讓 IT 人挑戰，連續 30 天不間斷每天寫一篇文章。
今年因故臨時決定參賽，選了一個自己過去經常被問到的問題「付費版 GitLab 到底差在哪裡？」來當作內容主題。然而這畢竟是一個會談到「付費功能」的內容主題，所以恐怕會變成某種「功能介紹」、「付費功能推廣」的「工商文」，所以最後就直白的將參賽主題訂為《就是工商，為什麼要使用付費版 GitLab？》。
30 篇文章已經全部發佈在「iT邦幫忙」網站上，我暫時也沒有將文章搬家的計劃，因此對於該系列文有興趣的讀者，可以直接透過下面整理好的超連結前往閱讀。
由於鐵人賽是連續 30 天的考驗，所以經常會參賽到一半開始沒靈感，或是不小心歪到偏離參賽主題的內容去；我這次也很明顯的出現這種狀況，所以下面的超連結已經幫大家將各篇文章的內容分類，讓各位可以比較容易的找到想讀的內容。
文章超連結 參賽開場白 這是最沒內容的開場白，如果你想感受一下我當初起心動念臨時參賽的心情，再去閱讀吧！
Day 1：為什麼要寫這個主題「就是工商，為什麼要使用付費版 GitLab？」 企業通常會為了哪些功能付費 一般使用者與企業，兩者會願意付費的功能是不同的。
Day 2：企業在意的付費功能可能跟你想的不一樣 Day 3：企業通常都在意哪些功能 GitLab 付費功能介紹 這次系列文有挑了幾個「付費功能」來介紹。
Day 4：自架 GitLab 的高可用方案—GitLab Geo Day 5：如何避免因為 AD 故障而無法登入 Self-managed GitLab？ Day 6：GitLab 請賜給我更多的 User 權限自主權！ Day 7：稽核你不要來，這裡沒有什麼好查的啦～ Day 8：用數據來證明你導入 DevOps 是有效的！ Day 18：Security 功能 - Pre-build scanning Day 19：Security 功能 - Post-build scanning Day 21：GitLab 的 AI 功能 Duo Day 22：GitLab 的 Incident management 功能 Day 23：GitLab 的 Portfolio Management 功能 GitLab 歷史與功能發展 這邊要提醒一下，歷史與功能發展我並非用一個很有系統的方式整理，而是我自己在讀完 GitLab 公開的 History，以及每一則 GitLab Release note 後，自我心證的挑了一些資訊記錄下來，因此這數篇文章比較像是我個人的筆記，裡面比較有可讀性的只有各篇文章文末的感想。...
如上一篇文章提到的，延續去年，今年在 DevOpsDays Taipei 2024 也規劃了一軌的 DevOps Bootcamp，其中安排了兩場體驗工作坊。
工作坊最終在經過理想與現實的交戰之後，決定由盧建成與我各自負責一場工作坊。
另外，由於 DevOps Bootcamp 整軌議程會固定使用瓶蓋工廠台北製造所 的 M 棟場地，因此預設這會是至多 160 人參與的工作坊。
主題發想 由於是「體驗」工作坊，重點在於「體驗」，因此打從一開始，我就設定工作坊的形式是不需要使用「電腦」，並且要有大量的討論與交流。
但問題是要「體驗」什麼？
在與盧建成討論之後，我希望他能繼續銜接 Biz 與 DevOps 的議題，讓新手知道 DevOps 不能少了 Biz。因此他那邊會從 BizDevOps 為出發點，思考關於團隊協作、文化、溝通有什麼適合新手體驗的主題。
而我這邊則繼續照顧最常見的新手需求之一，即是 CI/CD；畢竟談到 DevOps 時，大家最常聽見的第一句話依舊是「你們有做 CI/CD 嗎？」。因此我繼續從 DevOps 最基本的工程實踐 CI/CD 為出發，來思考有什麼適合放在新手村的體驗工作坊。
構思內容 我自己過去設計過一些 DevOps 工作坊，也講過幾場 GitLab CI/CD 實作工作坊，算是插電與不插電兩種類型的工作坊都有一些經驗。更早之前在 2017 第一屆的 DevOpsDays Taipei 時也參加過 EXIN 的鳳凰專案沙盤工作坊，以及過去也參加過幾次敏捷社群其他講師有使用大量「教具」的工作坊。
因此一直以來，我就很想要設計製作一套自己的 DevOps 教具與課程，只是遲遲未能找到合適的機會將它實現。（其實我還有另一份胎死腹中的 DevOps 教具 idea，還留在我的筆記本中。）
綜合上面各種過去經驗，以及這次 DevOps Bootcamp 新手村的主題發想，我決定在這次的「體驗工作坊」，讓新手認識 CI/CD 是一件涉及範圍可以很窄也可以很廣的一件事；它本質上是一項「變革」，根據你組織與團隊的現況，不同組織當前要處理的議題範圍是不同的。因此最後我決定，不如就讓大家一起在工作坊上，感受一條龍工程師的痛苦吧！
（迷因出處：網路迷因圖）
補充：我覺得新手需要的並不是那些單一的工具細節，雖然使用哪一套 CI/CD 工具也是需要思考的議題，但那並非最重要的事。...
按慣例用一篇文章記錄 DevOpsDays Taipei 2024。
（如果有看到文中的紀錄有誤之處，還請通知我修正，謝謝）
活動基本資料 主辦單位：台灣敏捷協會、台灣敏捷社群、DevOps Taiwan Community、Taipei HashiCorp User Group、iThome 官網：https://devopsdays.tw/2024 日期：2024/07/10 ~ 2024/07/11 地點：瓶蓋工廠台北製造所 Keynote：共 4 場 分堂議程：共 39 場 工作坊：共 15 場（其中 2 場是 DevOps Bootcamp） 贊助商：共 14 家 活動人數：超過 800 人 活動共筆：https://hackmd.io/@DevOpsDay/2024 （今年是 DevOpsDays Taipei 首次使用「瓶蓋工廠台北製造所」這個活動場地。）
持續許願 如同我在今年開場時自嘲說的，在 DevOpsDays Taipei 的組織者當中，我是負責許願（及推坑）的那一個。
（專門推坑的）
今年許了哪些願望呢？
繼續維持開放空間會議 繼續辦一整軌的 DevOps Bootcamp（新手村） 多一點 Trunk-based development 的主題 少一點只是單純介紹工具的主題 適度增加國外講師的數量 針對上面的願望，一個一個簡單聊一下。
開放空間會議 我在很多公開場合都提過，自從在 DevOpsDays Taipei 2017 舉辦與參加過「開放空間會議」（Open Space Technology，簡稱 OST）之後，我就大受震撼。
原來研討會不只可以透過單向的演講為與會者帶來價值；透過適度的引導與空間安排，讓與會者們建立雙向（多向）交流的活動也同樣具有價值，且甚至有可能帶來超過單向演講的價值。
因此 DevOpsDays Taipei 絕對要保留一個「空間」舉辦 OST。...
前言 感謝 iThome 再次邀請，由於自己從 2023 年末有較多機會接觸 MLOps 的議題，同時也注意到 GitLab 默默地有在開發 MLOps 相關功能，因此就決定這次在 iThome Cloud Summit 2024 要分享 MLOps 的內容。
其實我本來的如意算盤是想著，等到 7 月 Cloud Summit 舉辦時，GitLab 差不多也已經正式推出新功能 Model Registry，這樣時間剛好，我就能用新功能來規劃一個簡單的 Lab。
但誰知道原廠遲遲未能正式釋出 Model Registry，在 6 月底最新 Release 的 17.1 版，Model Registry 依然處於 beta 狀態，因此最後只能放棄原本的計畫了。
Lab 內容規劃 本次的 Lab 內容一如往常，前半場會是簡短的演講，先向學員分享一些基礎知識，讓學員後續在操作 Lab 時，能更理解我想要傳達的內容。
演講的簡報已經上傳，有興趣的朋友可以前往觀看。
簡單解說一下，整個 Lab 的設計思路：
採用 GitLab 原廠的 Example Code 與流程為基底，但稍微調整內容順序，組合出我希望能讓學員體驗的內容。 Lab 預計要讓學員體驗以下內容： 訓練 Model 需要 Data，所以在訓練之前，你應該會有別的 Data Pipeline 吧？因此會讓學員在 GitLab 上建立一個很簡單的 Data Pipeline，然後將 Data 存放在 Job Artifacts 中。 建立一個 ML Project，並且從 Data Pipeline 取得清理乾淨的 Data，接著訓練 Model，最後查看儲存在 Model experiments 的成果。 建立第二個 ML Project，但在訓練 Model 之前，要先 build container image，為後續訓練 Model 建立一個可用的環境。 有了環境之後，接著訓練 Model，一樣可以在 Model experiments 查看成果。 設定排程 Pipeline 定期評估 Model。 如果時間足夠，可以讓學員試著手動下載訓練好的 Model，然後手動上傳到 Model registry 功能。 透過上面的內容規劃，希望學員能注意到 MLOps 流程中需要關心幾件事： 訓練 Model 是需要有 Data 的，那是否應該要關心一下 Data Pipeline 的規劃，以及準備好的 Data 該如何讓下游的資料科學家可以方便的取用。 訓練 Model 也是需要有一個「環境」，這個環境當然也可以做成 Container，那一樣會有環境的相依性、版本、管理及維護的議題。 開發（訓練） Model 與開發軟體，是很不一樣的流程，你不能直接拿軟體開發流程的經驗，硬是套用到 Model 訓練的世界。對於迭代及交付頻率的要求不同，需要管理的產出物、Report 也不同。單就功能面來舉例，最少你也需要準備一個可以方便記錄 Experiments 的功能，而且這些功能如果不夠簡單方便好用，資料科學家可是不會想用的。 Lab 操作步驟 如果你這次沒來現場參加 Lab，又或者你是有來現場，但沒能做完 Lab 的學員，那我已經將操作步驟改編成可以在 gitlab....
前言 繼續延續前兩篇關於 GitLab CI/CD Components 的文章。
Reuse CI Job 的新方法：GitLab CI/CD Components 為什麼你應該改用 GitLab CI/CD Components？ 這次要介紹的是如何將你做好的 GitLab CI/CD Components 發佈到 GitLab CI/CD Catalog，將你精心做好的 CI/CD Components 貢獻成為 CI/CD 界的開源專案，讓大家都能使用你開源出來的成果。
操作步驟 完成你的 CI/CD Component 首先第一步，請先完成你的 CI/CD Component，但這個「完成」需要做到什麼程度呢？我認為需要達成以下幾個條件：
按照 GitLab 原廠文件，正確的規劃與撰寫 CI/CD Component 的內容。請注意自己的 Project 結構是否正確、spec: 與 CI Job 內容是否撰寫正確、inputs: 的規劃是否合適。 不只是建立 Tag，還要為每一次的版本釋出建立 Release Page，讓使用者可以知道每一次的 Release 差異，讓使用者更容易知道 CI/CD Component 的版本更新歷程。（特別提醒：原廠文件有提到，目前要將 CI/CD Component 發佈至 CI/CD Catalog 時，建立 Release 是其中一項必備動作！本文後面會有更多說明。 ） 為你的 CI/CD Component 撰寫正確、易讀的 README....