一條龍工程師無法完成的 DevOps Pipeline 體驗工作坊

如上一篇文章提到的,延續去年,今年在 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 工具也是需要思考的議題,但那並非最重要的事。...

August 2, 2024 · Cheng Wei Chen

在 GitLab CI Pipeline 運用 SonarQube 做程式碼品質分析

前言 如果問到哪裡有免費的程式碼品質分析(掃描)工具,這幾年大家第一時間多半都會回答 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....

December 9, 2023 · Cheng Wei Chen

將 GitLab CI Pipeline 的執行結果,整合至 Merge Request 中

在多人協作的軟體開發流程中,運用 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 產生的重要資訊。...

November 30, 2023 · Cheng Wei Chen

善用 JUnit XML 格式,將各種 Reports 整合至 GitLab CI Pipeline

前言 在上一篇文章,我介紹了在 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。...

November 19, 2023 · Cheng Wei Chen

在 GitLab CI Pipeline 執行自動化單元測試

文章更新紀錄: 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 的規劃。...

November 11, 2023 · Cheng Wei Chen

第 11 屆 iT 邦幫忙鐵人賽(2019) - 和艦長一起 30 天玩轉 GitLab

今年艦長發了個瘋,在第二個小孩剛出生沒多久、即將舉辦 DevOpsDays Taipei 2019 (我擔任其中一位組織者)的狀態之下,參加了「第 11 屆 iT 邦幫忙鐵人賽(2019)」。 這次參賽的主題為「和艦長一起 30 天玩轉 GitLab」,本來想要用一個虛擬的團隊作為案例,分享關於 GitLab 的使用經驗,但實際上場之後才發現當初規劃的太美好,事前準備的不夠充分。雖然順利完賽,但案例規劃的並不完整、內容深度也不如計畫,最終撰寫的成果仍是較基礎的 GitLab 操作文章。 (This article has been translated into English.) 目前文章依然留存於「iT 邦幫忙」網站上,暫時先不一篇篇的搬到我私人的部落格,先用超連結的方式處理: iT邦幫忙網站提供的30天文章列表 下面直接附上 30 篇文章連結,並做一個簡單的分類整理: (鐵人賽文章撰寫時,使用的 GitLab 版本主要是 12;後續出版為書籍《和艦長一起 30 天玩轉 GitLab》第一版時,版本為 13.x;2022 年改版《和艦長一起 30 天玩轉 GitLab》為第二版時,版本為 15.x。) 基本認識 前言 安裝 GitLab GitLab 管理與權限 Admin Area—維運 GitLab Server 的管理者後台 GitLab 的 User 與權限控管 GitLab Workflow GitLab: 從建立 Group 和 Project 開始 初探 GitLab Workflow & GitLab Flow GitLab 和 Mattermost GitLab: Issue、Issue Board 和 Kanban GitLab: To-Do List 與 Milestones GitLab: Commit & Merge Request GitLab: Issue Templates & Merge Request Templates GitLab: Project Wiki & GitLab Pages GitLab Cycle Analytics & Charts GitLab CI 架設 GitLab CI Runner GitLab: 建立第一條 CI/CD Pipeline CI/CD Pipeline 之 stage: build CI/CD Pipeline 之 stage: deploy CI/CD Pipeline 之 stage: test CI/CD Pipeline 之 stage: prod-deploy CI/CD Pipeline 之 Container CI/CD Pipeline 之 CI Service 掛掉時該怎麼辦? GitLab CI 之 CI trigger、API 與 ChatOps GitLab CI 之 Scheduling Pipelines GitLab Auto DevOps GitLab: Auto DevOps 之牛刀小試 GitLab: Auto DevOps 之牛刀小試 2 - K8S GitLab: Auto DevOps 之牛刀小試 3 - Auto Deploy (Production) GitLab: Auto DevOps 之牛刀小試 4 - Auto Browser Performance Testing GitLab: Auto DevOps 之牛刀小試 5 - Auto Monitoring GitLab: Auto DevOps 之牛刀小試 6 - Customizing 回顧與總結 回顧與總結 以上就是 30 天鐵人賽的所有文章。...

November 14, 2019 · Cheng Wei Chen

COSCUP 2017 - Ansible & GitLab CI/CD workshop 101

今年(2017)的 COSCUP 採用與過往不同的徵稿方式,而 DevOps Taiwan 社群也共襄盛舉貢獻了三場分享。 縱然我們知道談到 DevOps 時,不該只談論其中的技術層面,更應該要包含文化層面的議題,不過在這種技術力爆表的場子,就請原諒我們還是會以技術為主要的分享內容。 (不過這麼說有失偏頗,因為 COSCUP 2017 還是有像是「如何將女友培養成開源貢獻者」這種軟性的主題,因此只要有心,還是能夠分享非技術主題的。) DevOps Taiwan 這次由三位講者,分別負責一場分享,首先我們邀請了部落格「小城故事不多-科技部」的蔡宗城(smalltown)為我們分享「Infrastructure As Code」。 第二位講者則是大家從小看到大的部落格「凍仁的筆記」其主人凍仁翔,為我們分享「DevOps 人一定要知道的 Ansible & GitLab CI 持續交付技巧」。 最後,則由小弟我延續凍仁翔的題目,帶來一場簡易的 Workshop 「Ansible & GitLab CI/CD workshop 101」。 Ansible & GitLab CI/CD workshop 101 這場 Workshop 在構思時,預定的難度是 101 的程度,但實際動手設計內容時發現要講多淺才算是 101?要多複雜才算是 201、301 或更高的難度?有一些難以拿捏,總之就請各位保持著一種開開心心的心情來跟著下面的內容操作練習即可,到底是 101、201、或甚至根本只是幼幼班就先拋在腦後吧(逃)。 回到正題,這場 Workshop 希望能幫助大家藉由實際操作,能夠體驗看看 CI / CD、Automation,以及當我們在談到開發流程的規劃,關於 workflow 或 pipeline 的規劃時可能要注意些什麼? 要注意的是,這個 workshop 的案例只是一個簡單的示範,不同的公司、組織或團隊在規劃 pipeline 時會有各自的考量,因此在實際體驗之後,當你回到自己的團隊時,務必要根據你自身的情況進行規劃,如此才能建構出最適合你團隊的 CI / CD pipeline。 所需工具 本次我們會使用的工具如下: Ansible - 我們會利用 Ansible 撰寫一些簡易的自動化腳本。 Docker Community Edition - 用來運行你自己 CI Runner 與模擬 Web Server。 續上,一台可以跑得動 2-3 個 Container 的主機(可以是你自己的筆電、雲端的 VPS,或其他。),預計會消耗 5 GB 以內的硬碟空間,因為在 Workshop 使用的是個人自建又大又肥的 Container。 GitLab....

August 5, 2017 · Cheng Wei Chen