Cheng Wei Chen | 艦長

在多人協作的軟體開發流程中，運用 Git 及 Branch 已經是一件再平常不過的事情了，想必大家多少都有經歷過多人開發的工作情境，在這樣的情境中，多位開發工程師會各自在不同的 Branch 開發功能，最後透過 Merge Request（MR）將程式碼進行合併。 在這樣的情境中，MR 肩負了重要的任務，它會是一個重要的資訊彙整、進度同步、討論、稽核⋯⋯的關鍵點。 既然 MR 如此重要，同時它又是團隊協作及軟體開發流程中經常發生的一件事，可以的話，我們應該要依據團隊實務上的需要，讓使用者可以更方便的在 MR 頁面彙整並瀏覽各種必要的資訊。 GitLab 原廠當然有注意到 MR 的重要性，因此在 GitLab 免費版中，MR 頁面已經有整合了多項必要的基本資訊。（當然付費版比起免費版擁有更多的整合。） 首先在 GitLab 的 MR 頁面，可以看到 Overview、Commits、Pipelines 與 Changes 四個分頁。後三者比較單純，分別用來讓使用者快速一覽當前的 MR 包含了哪些 Commits、觸發了哪些 Pipelines、以及實際上有哪些檔案被異動了。 在 Overview 的分頁中，則是資訊大彙整，包含了這項 MR 的基本資訊、最新一條 CI Pipeline 的執行狀態、MR 是否有通過 Code Reviewer 的 Approval、以及團隊夥伴是否有對此 MR 留下各種 Comments。 如上圖所示，在 MR 的 Overview 頁面上，有整合了最新一條 CI Pipeline 的執行狀態，但你只能知道 Pipeline 最終是成功還是失敗，如果你想要知道 CI Pipeline 內產生的更多資訊（例如：CI Job 產出的 Reports 內容），一般來說你只有兩個選擇： 付錢升級，啟用付費功能（如果有你需要的功能） 點擊連結，前往 CI Pipeline 查看對應的 CI Job Log 及直接瀏覽 Job Artifacts 的檔案 如果上面兩種方法你都不滿意，那也許你可以考慮一下本文將要介紹的第三種方法！即是運用 GitLab API，讓 CI Pipeline 自動將 CI Job 執行結果發佈到 MR 的 Comments 中，藉此實現在同一個 MR 頁面即可看到更多 CI Job 產生的重要資訊。...

前言 在上一篇文章，我介紹了在 GitLab CI Pipeline 執行 Unit test，本文繼續延續上篇文章的內容，這次我們要進一步的善用 GitLab CI 的 artifacts:reports:junit 功能。 如同我在上一篇文章說明的，GitLab CI 能夠解讀 JUnit XML 格式的 Report，將內容直接整合在 CI Pipeline 的 UI 上。既然如此，是不是我可以不限於 Unit test 的 report，而是將任何存成 JUnit XML 格式的內容都丟給 GitLab CI 呢？就讓我們來實驗看看吧！ 操作步驟 實驗一：GitLab CI 是否接受，非 Unit test tool 產出的 JUnit XML 第一個實驗，讓我們找一個不是 Unit test，卻又能產出 JUnit XML 格式的工具來實驗，看看 GitLab CI 是否接受該工具產出的 XML。 這裡我挑中的是 Python 圈的一個新工具 ruff。 自從 Rust 這個程式語言開始大紅大紫之後，大家似乎都看上 Rust 在 Performance 所帶來的優異表現，於是各種工具都紛紛開始出現有人用 Rust 重新撰寫，而 ruff 就是其中一個例子，它就是用 Rust 所開發給 Python 使用的 Linter。...

文章更新紀錄： 2023.11.11 發佈 2023.11.12 更新內容 前言 在介紹 CI 持續整合的觀念時，我經常會分享一句話「沒有自動化測試，不要說你是在做 CI」。在 CI Pipeline 中，我們會設置各種自動化測試的 CI Job，讓 CI Pipeline 不只是實踐自動化，而是能成為一位守護「最低限度品質」的守門員。 既然自動化測試是 CI Pipeline 的重要關鍵，理所當然 CI 工具與測試工具兩者就會有各種互相合作與整合的狀況出現啦！ 在這篇文章，我們就從大家最常聽見的測試 Unit test 為主題，介紹如何在 GitLab CI Pipeline 中執行自動化單元測試。 操作步驟 1. 準備你要測試的程式碼與 Unit test 想要執行 Unit test，首先當然你需要一份程式碼，然後為你的程式碼撰寫對應的 Unit test 啦！ 但本文重點不是程式開發與怎麼寫測試，所以這部分就請容我跳過，就讓我直接在 GitHub 上隨意搜尋，挑選兩種不同程式語言的 Unit test example 作為範例。 首先是 Python，可以找到這個範例 ptracesecurity/pytest-example 接著是 PHP，可以找到這個範例 php-actions/example-phpunit 2. 規劃你的 CI Job 與執行環境 因為本文我們只針對 Unit test 這件事，因此就先省略不談整條 CI Pipeline 的規劃，直接切入單一 CI Job 的規劃。...

首先，要先表達滿滿的感謝！ 感謝所有的工作人員、志工、贊助商、講師、社群、以及所有報名參加 DevOpsDays Taipei 2023 的與會者，讓今年的 DevOpsDays Taipei 能以超乎以往的規模舉辦，真心感謝，沒有大家的支持，今年的 DevOpsDays Taipei 2023 絕對不會這麼成功。 今年真的感觸很多，當然要寫一篇文章來記錄一下！ 活動基本資料 主辦單位：台灣敏捷社群、DevOps Taiwan Community、Taipei HashiCorp User Group、iThome 官網：https://devopsdays.tw/2023 日期：2023/09/25 ~ 2023/09/26 地點：會場 1（臺北文創 6F）、會場 2（松山文創 2F） Keynote：共 5 場 議程：共 31 場 工作坊：共 14 場 贊助商：共 24 家 活動人數：超過 950 人 活動共筆：https://hackmd.io/@DevOpsDay/2023 許願成真 打從去年在 DevOpsDays Taipei 2022 的場外跟許多朋友聊天而產生各種想法之後，今年在開始籌備 DevOpsDays Taipei 2023 時，我就是各種許願（笑）。 主要的許願有幾項： 一定要有開放空間會議（Open Space Technology） 來一軌專門給新手的議程——DevOps Bootcamp 想要邀請一些特定的講師，來講特定的題目 做 6 款紀念服 這些願望，今年全都實現了。 說到這裡，我真的要特別感謝 iThome 執行力超強的 Chris！要是沒有他，DevOpsDays Taipei 2023 絕不可能如此成功，也無法實現各種許願。...

前言 前幾天在 GitLab 社群中看見有人針對在 Windows WSL 上架設 GitLab 提出了一些疑問，覺得這是一個可以動手嘗試的題目，因此也抽了一個空檔快速的實驗了一次，下面就紀錄我這次實驗的過程與操作步驟。 操作步驟 1. 安裝 WSL WSL 目前可以直接在 Microsoft Store 中安裝，如下圖那個看起來有點喜感的企鵝，就是我們要安裝的 WSL。 2. 確認 WSL 版本 WSL 安裝完畢後，接著我們要進入 PowerShell，在 PowerShell 中輸入 wsl -l -v 來確認一下 WSL 的版本，以及目前是否已經有安裝了 Linux 環境。 如果要進入 PowerShell，可以在 Windows 的搜尋列中輸入 PowerShell 來啟動 PowerShell。 啟動 PowerShell 後，畫面上會出現一個類似下圖的「命令提示字元」視窗，但不同的地方是在 Command Line 的最前面會有 PS。 如上圖，輸入 wsl -l -v 即可查看 WSL 的版本與目前是否已經安裝了 Linux 環境；如圖片所示，在我的 WSL 中尚未安裝任何 Linux 環境。 3. 在 WSL 中安裝 Ubuntu 首先，我們要確認 WSL 可以安裝哪些 Linux 環境，在 PowerShell 中輸入指令 wsl --list --online。...

前言 延續 DevOps，DevSecOps 一詞在 IT 圈內也已經不是一個新詞，市面上有非常多的廠商都在銷售號稱與 DevSecOps 有關的產品，亦有不少來自資安圈的講師分享過 DevSecOps 的主題。就如 DevOps 一樣，DevSecOps 同樣也具備著「十個講師會有十一種 DevSecOps 的內容」的現象，但無論如何 DevSecOps 絕對是 DevOps 的其中一位後繼者，是當前企業多少會開始了解與碰觸的一項熱門議題。 在今年 2023 的 iThome Cloud Summit，我邀請了 GitLab 原廠的 Staff Solutions Architect - Toshitaka Ito，以及另一位 GitLab Hero - Mouson (墨嗓) ，一起針對 DevSecOps 這個主題，規劃了一場「輕輕鬆鬆體驗 DevSecOps」的 Hands-on Lab。 議程簡介 這次投稿的是 Hands-on Lab，以下是本次提供給主辦單位的議程簡介資訊： 延續 DevOps 風潮，其實 DevSecOps 一詞自 2012 年被人提出後，至今也超過 10 年了。DevSecOps 作為一個根源自 DevOps 而來的新詞，我們會發現它跟 DevOps 一樣有著「似乎沒有標準定義」、「不同企業的實踐方式皆不相同」的現象。 課程目標 • 認識 DevSecOps • 體驗來自 GitLab 的 DevSecOps 流程 • 實際體驗如何修復程式碼中含有的漏洞...

千呼萬喚始出來，認識許久的前輩、部落格 Complete Think 的主人 Rick 大大終於出書了。隨著新書資訊已經對外公開，我也終於可以把這個好消息分享給大家了。以下就全文獻上我為 Rick 的著作《SRE實踐與開發平台指南》所寫的推薦序，希望大家會喜歡。 啊，想要買書的這邊請喔！購書傳送門：《SRE實踐與開發平台指南》 Complete Think—知識工作者都必須學習的專業能力 如果你身處在 IT 或軟體開發相關產業，你可能會聽過下面的這些經典問題「星期五下班前可不可以部署？」、「為什麼老工程師要用註解的方式留下目前用不到的程式碼？」、「ＯＯＸＸ很潮，我們要不要用？」⋯⋯當你遇到這些經典問題時，不知道你第一時間的反應是什麼？是立即帶著（正面或負面）情緒回答呢？還是一笑置之？又或者是你會先退後兩步，釐清問題的範圍、全貌及背景資訊，然後再回答問題呢？ Rick Hwang，一位我有幸在社群中結識亦師亦友的前輩，「Complete think」不僅是他個人技術部落格的名稱，也是他個人思考方式的最佳寫照。如果你問我什麼是現代知識工作者都必須學習的重要能力，我認為答案會是「如何思考、看透問題背後的問題（QBQ）、洞悉問題本質、以及建構自己的知識（思維）體系」，而在 Rick 身上，我看見了這些能力的真實體現。回到前面的經典問題，如果是讓 Rick 來回答它們，你絕不會聽見「等到你老了，就知道為什麼要這麼做」，反之你會看到他清楚的陳述問題背後的問題，並提供具有清晰前提要件和背景資訊的完整論述。 有沒有一本書，都還沒進到正文，只是閱讀作者給讀者的「如何閱讀這本書」，就令人體驗到受益無窮和開啟思維的體驗？有！就是 Rick 的這本《SRE實踐與開發平台指南》。這本書乍看是在談論如何實踐 SRE，實則深入探討了能幫助團隊和組織運作順暢的各種架構和原則。 即便你不是 SRE，但只要你仍在 IT 或軟體開發相關產業，你絕對不能錯過這本書。而如果你已經是 SRE，你又不希望自己只是一位 Server Reboot Engineer 或 Service Restart Engineer，那麼你最好說服整個團隊一起結伴細讀這本能幫助你們學習 Complete think 的好書。學習作者是如何運用矩陣思維、從不同的層次來看待各種問題與現象，從更宏觀全貌的角度進行思考，明白如何依據自身的時空背景，找到適用於你們問題的「適切答案」。 最後，讓我再問一次「星期五下班前可不可以部署？」，想知道答案嗎？去找吧！Rick 已經將一切的答案都放在他的書中了！ —— DevOps Taiwan Community 志工 / 前 Organizer 陳正瑋（艦長） （再次附上購書傳送門：《SRE實踐與開發平台指南》）