按慣例用一篇文章記錄 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....
背景資訊 在 2022 年底時，有一個機會和 DDD Taiwan Community 的社群朋友聊天，本來是聊天，但聊到最後變成邀請他來幫團隊帶了幾次 Event Storming。
因為有了當時的經驗，後續順利將這項「引導工具」引入公司、團隊，甚至是客戶端，因此秉持著「取之於社群，回饋於社群」的想法，將自身獲得的經驗，於 2024.02.29 回饋分享至 DDD Taiwan Community。
KKTIX 的活動報名頁面 DDD Taiwan Community 在 FB 上發佈的活動貼文 筆記女神 Anna Su 為當晚活動留下的筆記文 因為這是一個來自於我個人、團隊及運用在客戶端的經驗談，因此我將主題與內容設定為較軟性的主題「Event storming 是個好東西：幫助團隊看見全貌，引發團隊變革新契機」，主題的簡介如下：
當你想要導入 CI/CD、DevOps 或 OOXXOps 時，你會如何幫助所有的夥伴建立相同的共識？讓大家可以看見相同的全貌及痛點？
當團隊開始重視 DevOps 核心精神中的「交付價值、持續改善」時，我們確實需要一些不同於傳統會議與組織溝通的方法，來輔助不同的部門及團隊打破 silos 共同看見整體流程的完整面貌，畢竟我們都知道 DevOps 從來都不是一條龍工程師自己的事情。
在本次的 Meetup，我將會聊一聊幾個來自真實場景的小故事，分享這段由 Event Storming 所觸發的團隊變革旅程。
內容分享 因為這次分享的經驗都來自於目前任職的職場，因此針對內容有做了一些去識別化，就請容我不公開釋出完整的簡報，下面就以幾張簡報快速說明這次分享的內容。
如前面提到的，這次設定的是一個很軟性的主題，主軸就是想要分享這一段時間以來，基於 Event Storming 得到的一些經驗與學習。
其中，最深的感受就是，Event Storming 是一個很棒的「引導工具」（好東西），這個好東西它好在哪裡呢？它好的地方在於，透過它我們有機會能幫助團隊「看見全貌」，藉此為「變革」這件事，創造一個「契機」。
同樣如前面所述「取之於社群，回饋於社群」，我個人能夠認識與學習 Event Storming，歸功於過去在社群中認識的國昭與 Tim，再次特別感謝他們兩位。
本來 DevOps Taiwan Community 二月底也要舉辦 Meetup，但後來因為原定的講師時間喬不攏，再加上剛過完農曆新年，也不容易臨時安排其他備援講師，最後因緣際會的就跟 DDD Taiwan Community 的組織者 Kim 談定，二月底就由 DDD Taiwan 主辦 + DevOps Taiwan 協辦的方式來結束這一回合，這裡也再次感謝 Kim 接受我的臨時提議。...
前言 在上一篇文章，我們試用了 GitLab 的新功能 CI/CD Components，接著讓我們聊一聊為何我們在 GitLab 應該要改用 CI/CD Components 來製作我們的 CI/CD Template。
截至 2024.1.20 為止，我認為改用 CI/CD Components 可以帶來三個好處。
好處 1：讓設計與規劃 Reuse CI Job 的方式更一致 首先，讓我們先做一個簡單的比較，大家想像一下，在過去沒有 CI/CD Components 的時代，我們是如何利用 include: 來設計 CI/CD Templates？如果你希望別人在使用你的 CI Templates 時，要依據需求填入一些 input，你會怎麼做？多半會使用 variables: 去定義一些 Variables 吧？
在那樣的狀況下，為了在 Templates 中提供 Variables 使用上的彈性，讓自定義的 Variables 有 default 值，又能讓使用者可以順利覆蓋，我們會利用 Variables 的各種特性，或使用多層 include: 來設計 CI/CD Templates。
因此最終會做出多層 include: 的 .yml，並在其中撰寫 CI Job，然後搭配 CI Job，將需要填入的 input，都寫在 variables: 中，然後恐怕為了區別不同 CI Job 會用到的 Variables，經常還必須個別加上不同的前綴字，分別命名為 XXX_VAR1 或 OOO_VAR1。...
前言 隨著軟體開發的生命週期，除了程式碼，CI/CD Pipeline 也有可能會隨之變得越來越複雜。在過去 GitLab CI 提供了像是 include:、template: 及 extends: 等多種 Keywords 來幫助我們重構、規劃及管理我們的 CI/CD Pipeline，透過這些 Keywords，我們可以設計出屬於自己團隊及跨 Projects 共用的 CI / CD Templates，避免團隊重複造輪子，讓 Pipeline 及 CI Job 可以被重複利用。
筆者認為 GitLab CI 現有的這些 Keywords 已經足夠豐富，可以有效幫助團隊用一種有規劃及架構的方式來管理 CI/CD Pipeline。但問題是在這樣的規劃及架構背後，也代表著有一份屬於這個團隊的「GitLab CI/CD 知識與經驗」需要被記錄與傳承，這些知識與經驗，將會是團隊需要面對的另一項議題。
上述有關 CI/CD Pipeline 規劃及管理的議題，其實各種 CI Tools 的供應商都有注意到，隨著 CI/CD 工具鍊的整合越來越容易，其實可以發現供應商們不約而同都在思考著類似的議題——如何讓使用者可以更輕省的創建所需的 CI/CD Pipeline、如何減輕使用者在創建 CI/CD Pipeline 時需要擁有的先備知識量、如何更好的讓眾人一同維護 CI/CD Pipeline。
針對這些議題，GitLab 在版本 16.0 做出了一項新回應，從 16.0 開始實驗名為 CI/CD Components 的新功能，並且在 16.6 進入 Beta 開放大家試用。
在這篇文章，我們就來快速建立一個 CI/CD Component，試用一下這個值得我們期待的 GitLab CI 新功能吧！...
前言 如果你經手的經常是相同類型的專案，或者你是某種程式語言或 Framework 的愛好者，那麼在專案啟動的時候，多半會建立出固定的資料夾結構與檔案；同理，如果你的團隊有穩定的協作方式，在軟體開發流程中，採用了 GitHub Flow 或 GitLab Flow，那麼你可能在專案啟動時，固定會手動建立 main、develop、release 等多條 Branch。
無論如何，這些專案啟動的固定起手式，看似稀鬆平常，但累積起來也是會佔用團隊不少時間，再加上這都是一些固定且重複動作，做久了有時也是會覺得有些煩，甚至不小心就漏掉了某個必要的動作。
面對這樣的狀況，我們可以事先建立標準的 GitLab Project templates，讓團隊可以直接運用 Template 來省去這些重複的固定動作。
下面就介紹我曾經在 GitLab 建立 Project Templates 的方法。
付費功能：Custom group-level project templates 首先，如果你是 GitLab 的付費使用者，那麼恭喜你，GitLab 自 11.6 版即提供 Custom group-level project templates 功能。該功能讓我們可以將 Group 底下的所有 Projects 都變成 Templates，方便團隊可以盡情的為各種專案與情境，建立各種 Project Templates。
# 舉例來說，我可以建立一個名為 Project templates 的 Group # 接著在裡面建立許多的 Project，每個 Project 適用一種情境 Project templates: ## 可能有適用不同 Python 版本的 Tempalte python 3.9 python 3.10 ## 可能有特定 Python 版本 + 特殊情境的 Template python 3....