在 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

DevOps 推薦書單

(本文於 2018-06-14 21:56:01 更新。) 在某次機緣之下,與尊敬的 Ruddy 老師針對「 DevOps 推薦書籍」有一些簡單的交流。那時整理了手上的筆記,將收集到的 DevOps 書單整理在本文之中。如果你也有推薦的 DevOps 書單,歡迎與我交流!(本文將持續更新,歡迎推薦 DevOps 好書。) (本文同步發表於 Medium) DevOps 不只涉及觀念,也與許多的工具相關,但因為技術工具書,例如:Ansible、Docker、K8S 這一類著重於工具操作與使用的書籍,通常隨著工具更新的緣故,書籍的壽命都比較短。同時並非每一種工具都適用於所有的團隊,因此這類書籍就不收錄在此書單中。 這份書單會以保存期限較為長久的觀念型書籍為主。 Effective DevOps - Building a Culture of Collaboration, Affinity, and Tooling at Scale 這是一本由技術人撰寫的非技術書籍,本書主要在談 DevOps 文化,圍繞在書名副標的那四個項目 Collaboration、Affinity、Tool、Scale,以文化與組織發展為主軸貫穿全書。另外書籍的前面幾章也針對 DevOps 及 DevOps 相關的關鍵字提供了基本簡介,某種程度可以當成一本 DevOps 入門書,可由此再延伸閱讀更多的書籍。(繁中、簡中) Continuous Integration: Improving Software Quality and Reducing Risk 關於持續整合(CI,Continuous Integration)的經典必讀書籍,缺點是目前沒中譯本。 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation 關於持續交付(CD,Continuous Delivery)的經典必讀書籍,比較要注意的是因為英文版是 2010 年出版的書籍,因此書中範例提到的軟體會比較老牌一點。另外,在社群中也有前輩表示現今 Microservices、Serverless 等新觀念抬頭,這本書的部分內容應該可以配合這些觀念而有所更新。(繁中) The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win 知名的 DevOps 小說,如果當工具書來讀會大失所望,按其他前輩的說法,此書就是要當成小說與實際案例來看,請細細品味書中的劇情及小說人物遇到的困境,並且對照自己的經歷而有所反思,同時嘗試換位思考如果你是小說內的主角你會怎麼面對問題,如此一來才能體會書中的醍醐味。本書也是讓玄妙的 DevOps「三步工作法」首次面世的書籍。(繁中、簡中) The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations 由目前世界知名的 DevOps 顧問 Gene Kim 與他的好朋友們延續《The Phoenix Project》而撰寫的另一本書。如果覺得看完《The Phoenix Project》之後,對於玄妙的三步工作法依然不得要領,那麼這本《DevOps Handbook》就是你的救星。這本書透過案例與說明幫助你一步步實踐「三步工作法」,這些案例不乏許多知名的公司,像是 Google、Netflix、Etsy⋯⋯。(簡中) The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece 另一本值得列為 DevOps 必讀書籍的輕薄好書。本書簡短、輕快且直擊紅心的點出軟體開發的核心關鍵—交付價值,這也正是藏在 DevOps 背後的重要關鍵。若希望讓你的團隊順利踏上 DevOps 之旅,那麼最好讓組織、團隊及個人皆能共同意識到「交付價值」的重要性。(簡中) Site Reliability Engineering - How Google Runs Production Systems 有些人是這麼評論的 “SRE is Google’s version of DevOps”,在《SRE》書中也自己寫到「SRE 是 DevOps 模型在 Google 的具體實踐」。另外在 Gartner 所推出的 Gartner DevOps Model 中,也可以看見 SRE 有被列入其中。這是一本兼具觀念與技術實務的書籍,內容包含很硬的技術實踐與很軟的團隊文化,對於 SRE 有興趣者非讀不可,另外若對你而言 DevOps 與 Cloud Architect 的關係密不可分,那這也是非讀不可的好書。 The DevOps 2....

November 30, 2016 · Cheng Wei Chen