前言 隨著軟體開發的生命週期，除了程式碼，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....
前言 如果問到哪裡有免費的程式碼品質分析（掃描）工具，這幾年大家第一時間多半都會回答 SonarQube Community Edition。
（截圖日期：2023.12.04）
如上圖，SonarQube 原廠有提供多種 Edition，商業策略也與其他軟體供應商類似，提供 Community Edition 吸引廣大的使用者，並在 Developer Edition 與 Enterprise Edition 提供更強大的整合與進階功能。
本文就讓我們嘗試架設 SonarQube 9.9.3 LTS，並且在 GitLab CI Pipeline 中加入程式碼分析的 CI Job。
操作步驟 架設 SonarQube Server 老樣子，在這個時代，想要試用一個新服務最簡單的方式，就是想辦法利用 Container 快速將服務架設起來。SonarQube 原廠當然也明白這一點，因此早就準備好現成可用的 Docker image。
這裡我們要使用的 image 是 sonarqube:9.9.3-community。
請準備至少有 4GB RAM 可運行 Docker Container 的環境，然後使用下面的 docker-compose.yml 即可快速架設 SonarQube。
services: sonarqube: # 9.9.3 是 LTS 版本 image: sonarqube:9.9.3-community # SonarQube 需要相依一個 db，這裡我們選用 postgres db depends_on: - postgres_db environment: # 設定 postgres 的連線資訊 SONAR_JDBC_URL: jdbc:postgresql://postgres_db:5432/mysonar # 帳密建議可以改一下啦！ SONAR_JDBC_USERNAME: mysonar SONAR_JDBC_PASSWORD: mysonar # 如果你的 Container 跑起來有遇到一些 ElasticSearch 的錯誤，可以試著加上這個參數。 SONAR_ES_BOOTSTRAP_CHECKS_DISABLE: 'true' # 主要的 data 直接存放在 docker volumes volumes: - sonarqube_data:/opt/sonarqube/data - sonarqube_extensions:/opt/sonarqube/extensions - sonarqube_logs:/opt/sonarqube/logs # 預設使用 9000 port ports: - "9000:9000" postgres_db: # 2023....
在多人協作的軟體開發流程中，運用 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 絕不可能如此成功，也無法實現各種許願。...