隨著這些年參與社群活動，與各方高手交流，一直以來都很想以「DevOps」本身為題，留下些文字。
但總是以最近很忙、沒時間沈澱內容為藉口，一再拖延。
今年依然是忙到炸了，於是在頭被門夾到般神智不清的狀況下，決定就讓它更忙吧！
上面是我在今年參加「iThome 鐵人賽(2022)」時，於第一篇文章 Day 0 留下的文字，就如這段文字所述，一直以來都想要以「DevOps」為題，寫一些長篇系列文或科普文，但總是以「忙碌」為藉口，最終沒能有所產出。
這麼多年過去，今年終於忍不住了，我一定要寫，讓我寫，就算是用亂聊的方式，我也一定要寫些什麼，於是就誕生了這次的鐵人 30 篇文章。
這次參賽的主題為「重新認識 devops」，在系列文標題上，我故意使用小寫的「devops」，而不是當今常見的「DevOps」，不知道是否有人知道我的用意為何？這裡就先賣個關子，如果有人知道答案，可以私下與我聯繫，如果有答對正確答案，就讓我贈送你一本《和艦長一起 30 天玩轉 GitLab》（第二版）吧！（正確答案就讓我留到公布今年鐵人賽得獎名單的那天，再更新於本文吧！）
更新：鐵人賽得獎名單已經公佈了，所以我也來公佈我為何會使用小寫的「devops」，而不是當今常見的「DevOps」。其實原因很簡單，算是想要區別 2009 年 devops 這個詞剛出現沒多久，在那一個年代還很單純的 devops，以及經過多年直到現在已經被添加了各種多方意見，甚至是大幅偏向談論技術與工具的 DevOps。不知道你是否也覺得不同年代談到 DevOps 其實談論的內容也是大不同呢？總之，故意使用 devops 與 DevOps 算是我自己一點小小的「表態」，因此你會看到在今年的鐵人賽文章中，有些地方我會故意使用 devops，但有些則特意使用 DevOps，不曉得大家是否有注意到這項差異呢？今年的鐵人賽，因為是走一個拉迪賽的路線，並沒有談到太多深入的內容，如果未來有機會及餘力，希望可以重新再來一次「重新認識 devops」，將更多想寫的內容都一一落成文字。
目前文章依然留存於「iT 邦幫忙」網站上，一樣就暫時不搬回這裡，僅以超連結的方式連結各篇文章：
系列文「重新認識 devops」的內容大致上可以分成幾個主軸。（但因為是走想到哪寫到哪的路線，所以你也可以按著 Day0 ~ Day30 的順序讀下去。）
一、這次花了很多篇幅在講古。
Day 0：起心動念 Day 1：DevOps 只是個 hashtag Day3：2009 至 2022 DevOps 議題發展趨勢（一） Day4：2009 至 2022 DevOps 議題發展趨勢（二） Day6：DevOps 講古（一） Day7：DevOps 講古（二） Day8：DevOps 講古（三） Day13：從歷史看 CI/CD Pipeline（一） Day14：從歷史看 CI/CD Pipeline（二） Day15：從歷史看 CI/CD Pipeline（三） Day16：從歷史看 CI/CD Pipeline（四） Day17：從歷史看 CI/CD Pipeline（五） Day18：從歷史看 CI/CD Pipeline（小結） 二、也談了一些 DevOps 常見的老議題...
本文為系列文章《跟著 GitLab Auto DevOps 學習 CI/CD Pipeline》的第四篇，藉由逐一檢視並解析 GitLab Auto DevOps 背後的 Templates，讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。
在上一篇文章，我們學習到 workflow: 可以幫助我們控制在哪些條件之下才需要產生 CI/CD Pipeline。這次我們則是要進入第一個 Template - Jobs/Build.gitlab-ci.yml，看看 Auto DevOps 是如何實現同一個 CI Build 卻能適用於不同的程式語言。
此系列文清單：
跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（一） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（二） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（三） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（四） Jobs/Build.gitlab-ci.yml 首先讓我們直搗黃龍，直接查看 Jobs/Build.gitlab-ci.yml 的內容。
# 下面的版本來自 2022/02/04 的 https://gitlab....
在先前的文章，已分享過使用 JMeter 和 drill 進行小規模 Load Testing，今天延續同樣的主題，這次要使用另一個新興熱門的 Load Testing 工具 K6，試一試「如何透過 GitLab CI + K6 進行小規模 Load Testing」。
操作步驟 首先，K6 在 2021 年已經被 Grafana Labs 買下來了，但目前（2022/02/03）看來，K6 官網依然還維持原貌，沒有太大的變化，只是多掛上了 Grafana Labs 的 Logo。K6 有提供 Open Source 與 K6 Cloud 兩種方案，而本文將採用的是 Open Source 方案。
準備 GitLab Runner 老樣子，第一步我們要先預備合適的 GitLab CI 環境，應該不用再多做解釋，請先準備好能夠操控 Container 的 GitLab Runner，如果你不知該如何準備 Runner，又想要快速試一下本文的內容，那最簡單的做法是註冊一個 gitlab.com 帳號，然後建立新 Project 並使用官方提供的 Shared Runners。
準備 Docker image - K6 第二步，預備一個能夠運行 K6 的 Docker image。
這次很幸運，已經有現成的 Image 可以使用 loadimpact/k6...
本文為系列文章《跟著 GitLab Auto DevOps 學習 CI/CD Pipeline》的第三篇，藉由逐一檢視並解析 GitLab Auto DevOps 背後的 Templates，讓我們一起跟著 GitLab Auto DevOps 學習 GitLab CI/CD Pipeline。
在上一篇文章，我們學習了善用 include: 並透過合適的層級規劃，讓我們可以建立出屬於自己的 CI/CD Pipeline Templates。接著在本篇文章，我們要來認識在規劃 GitLab CI Pipeline 時，一個重要的進階功能 workflow:。
此系列文清單：
跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（一） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（二） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（三） 跟著 GitLab Auto DevOps 學習 CI/CD Pipeline（四） workflow 在本系列文的第一篇我們介紹 Auto-DevOps.gitlab-ci.yml 時，有稍微提到 workflow:，但當時只有快速帶過，說明關於它的一個基本認識，在文章中我是這樣解釋的：
workflow: 類似程式語言中的 if / else，在 GitLab CI 我們可以利用 workflow: 設置不同的條件，藉此控制 GitLab CI 判斷哪些情境之下，才需要產生 CI/CD Pipeline。...
《Accelerate》中文版即將上市 有在關注 DevOps 議題的朋友，應該都有看過《鳳凰專案》這本經典的 DevOps 好書。如果你有看過《鳳凰專案》那麼你一定也知道原文書籍的出版單位 IT Revolution 這多年來早已出版除了《鳳凰專案》之外，數本與 DevOps 相關的優質書籍。
今天要推薦的好書，即是 2018 年早已出版的《Accelerate》。但這次要推薦的不是英文版，而是經過多年終於能順利出版上市的《Accelerate》繁體(正體)中文版——《ACCELERATE：精益軟體與 DevOps 背後的科學》。
如果你每年都有在關注 DORA 發表的 State of DevOps Report，那麼這本《Accelerate》鐵定是你絕對不能錯過的好書。本書的作者群依然是 IT Revolution 與 DORA 背後的那群專業顧問與研究者，但有別於 State of DevOps Report，本書更深入的為我們探索並解答——何謂 BizDevOps？價值交付？以及在這波延續多年的 DevOps 轉型熱潮中，有哪些具體可供企業參考學習的建議。
《Accelerate》繁體(正體)中文版由 DevOps Taiwan Communitry 的志工江少傑主動向出版社推薦此書，並毛遂自薦擔任譯者，本書將於 2022/01/28 由旗標科技出版上市。感謝出版社與少傑的邀請，有幸能為此書撰寫簡短的推薦序，下面就一字不刪的直接附上整篇推薦序，希望這本好書都能成為各企業 DevOps 旅途上的一份助力。
推薦序全文 DevOps——自 2009 年誕生的這個玄妙 Buzzword，已擁有超過 10 年歷史；而在華文的 IT 圈中，我們莫約是從 2013~2014 年逐漸開始看見有人在網路上公開的提到 DevOps，至今雖不到 10 年，但也已有 6 至 7 年的時間。從前述的描述看來，不論是外文或華文 IT 圈，DevOps 都已是一個擁有多年歷史的老東西，面對這樣的老東西，不知你是否與我擁有著相同的疑問——「既然 DevOps 已被提倡這麼多年了，那究竟各企業實行 DevOps 的狀況又是如何呢？」
幸運的是我們不需要自己回答這個問題，因為自 2013 年開始，每一年在網路上公開發表的 State of DevOps Report 已為我們提供了解答。從每一年的 Report 中我們可以發現，雖然各企業實行 DevOps 的方向與進展有著明顯的差異，但隨著逐步實踐 DevOps，企業不約而同的有著相同的看法——DevOps 不只是軟體開發（Dev）與維運（Ops）的技術升級，若用另一個 Buzzword 來描述它，DevOps 即是一場關乎企業全體的「數位轉型」，軟體與科技能否幫助企業持續交付價值予客戶及利害關係人，即是其中的重要關鍵。...
本文為系列文章《跟著 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....
2022 的第一篇部落格，就從整理一則舊筆記開始吧！這次整理的舊筆記是關於在 Ansible 的 Varaible 中使用 boolean 的一些個人經驗。（本文使用的 Ansible 版本為 2.10。）
內文 在撰寫 Ansible Playbook 的時候，我們為了讓它能夠運用在多種情境，我們經常會使用到 when: 來控制各個 task 是否需要執行，例如：
# 當目標 Host 的 Linux 為 Ubuntu 時，才執行此 Task - name: "Create nginx sites-enabled link | (Ubuntu)" file: src: "/etc/nginx/sites-available/{{ APP_NAME }}" dest: "/etc/nginx/sites-enabled/{{ APP_NAME }}" state: link when: ansible_distribution == "Ubuntu" 而在剛開始學習 Ansible，對於 Ansible、Python 及 Jinja2 還不夠熟悉時，我們可能會寫出下面這種 when:。
# 希望做到當 Variable is_laravel 為 true 時，就執行 task - name: Create ....