在 ADO Pipeline 中使用 SonarCloud 進行自動化源碼掃描

作者： -

圖片
程式碼品質，絕對是每個專業開發團隊都會遇到的課題。

你知道的，當系統上線後，突然收到資安通報說發現了安全性漏洞，需要緊急修補。更糟的是，這個漏洞在開發階段就可以避免，只是當時沒人發現。然後你開始翻 Commit 紀錄，發現那段有問題的程式碼正是自己幾個月前寫的…這種情境難免會讓你冷汗直流。

這是為什麼我們需要在 SAST(Static Application Security Testing，靜態應用程式安全測試)與源碼掃描的原因。它就像是你的程式碼守門員，在你還沒意識到問題之前，先幫你把那些潛在的地雷給挖出來。

SAST 與 SonarCloud 的關係

靜態程式碼分析，也就是我們常說的原碼掃描，它不是去執行你的程式，而是透過搜尋常見的程式碼撰寫樣式，嗅出程式碼中可能的安全漏洞、程式碼壞味道(code smell)、技術債、還有那些可能會在半夜讓你接到客戶電話的潛在bug。

SonarCloud 則是 SonarSource 提供的原碼掃描雲端服務版，它基於知名的 SonarQube，但你不用自己架設伺服器、不用煩惱維護更新，申請完直接使用就行了。

對於使用 Azure DevOps 的團隊來說，兩者更是天作之合，因為官方有提供極其簡單好用的 Tasks 支援，整合起來超級輕鬆，幾個步驟就搞定。

而且，SonarCloud 支援超過 25 種程式語言，從 C#、Java、JavaScript 到 Python，基本上你想得到的它都有。它不只找出你的程式碼潛在問題，還會告訴你為什麼這段程式碼會是個問題、以及該怎麼修復，甚至連預估要花多少時間修復都幫你算好了。

我在 2020 年寫過一篇關於在 Azure DevOps Build Pipeline 中整合 SonarCube 的文章。但你也知道，科技業的時間流速跟外面不太一樣，四年過去了，很多東西都變了。

所以，是時候來個 2026 年的更新版了。

開始動手 : SonarCloud 帳號申請與設定

好，廢話不多說，我們直接開始。

首先，你需要一個 SonarCloud 雲端帳號。如果你有 Azure DevOps 帳號，就可以直接用它以 SSO 方式登入 SonarCloud，不用再另外註冊帳號。

你可以前往 https://SonarCloud.io/，選擇用 Azure DevOps 帳號登入。整個流程非常順暢，基本上就是點幾下同意授權，然後就進去了。

圖片

如果是第一次使用，登入後，可能會有點空虛，但沒問題，等等我們就會把專案加進來掃描。

這裡有個重點，SonarCloud 對於公開的開源專案是完全免費的。如果你的專案是 private 的，那就要考慮付費方案了。不過對於個人學習或開源貢獻來說，免費版已經非常夠用。

安裝 SonarCloud 擴充套件

接下來，我們要在 Azure DevOps 中安裝 SonarCloud 的擴充套見。

到 Azure DevOps Marketplace，搜尋 “SonarQube Cloud”，或是直接點這個連結:https://marketplace.visualstudio.com/items?itemName=SonarSource.SonarCloud

圖片

點下「Get it free」按鈕，選擇你要安裝的 Azure DevOps 組織，然後確認安裝。整個過程大概就是喝口咖啡的時間。

安裝完成後，你會在 Pipeline 的 Task 清單中看到 SonarCloud 相關的Tasks。這表示你已經成功跨出第一步了。

設定 SonarCloud 服務連接

這一步很關鍵。我們要讓 Azure DevOps 能夠跟 SonarCloud 溝通，這需要建立一個服務連接(Service Connection)。

在 SonarCloud 建立 Token

首先，回到 SonarCloud，進入你的帳號設定(Account Settings)。點選你右上角的頭像圖示，然後選擇「My Account」，接著，在「Security」頁籤下，你會看到「Tokens」的區塊。

圖片

給個名字，然後點擊「Generate Token」即可。一般來說，我們會給這個 Token取個有意義的名字，像是「Azure-DevOps-Pipeline」之類的。

記得要把產生的 token 立刻複製起來，因為它只會顯示這麼一次。如果你關掉視窗後才發現忘了複製，就只能重新產生一個了。

這個 Token 就像是你給 Azure DevOps 的通行證，讓它可以代表你跟 SonarCloud 溝通。所以千萬別把它放在公開的地方，也不要 commit 到版本控制裡。

在 Azure DevOps 設定服務連接

拿到 token 後，切換到 Azure DevOps，進入到Pipeline的設計畫面，添加一個Prepare Analysis Configuration task，然後進行Service connections的設定。

點擊「New service connection」，選擇「SonarCloud」類型。把剛剛複製的 Token 貼上去，給這個連接取個名字，然後儲存。

圖片

接著，我們需要在 SonarCloud 上建立對應的專案。

回到 SonarCloud 首頁，點擊右上角的「+」號，選擇「Analyze new project」。

圖片

接著不要點選 Import a new organization，而是直接選擇create a project manually。

圖片

這時候，SonarCloud 會讓你下拉選擇你的 Organizatio 並且填寫 Project Key。這兩個資訊非常重要，等一下在 ADO Pipeline 中會用到。設定好後，把這兩個值記下來，或是保持這個頁面開著。

在 ADO Task 中設定專案資訊

回到 Azure DevOps 的 Pipeline 編輯器，在「Prepare Analysis Configuration」這個 task 中，你需要填入剛剛從 SonarCloud 取得的資訊:

  • SonarCloud Service Endpoint - 選擇剛才建立的服務連接
  • Organization - 填入你的 Organization
  • Project Name - 一般來說我會建議你填寫你的 ADO 專案名稱。如此一來 Project Key 自動會是 Organization Name+Project Name。
  • Project Key - 唯一的專案識別值。

完成後，你應該會在服務連接列表中看到剛剛建立的 SonarCloud 連接。這表示 ADO 和 SonarCloud 兩邊已經可以溝通了。

在 Pipeline 中新增 SonarCloud 掃描任務

接著，請在 Build Pipeline 裡加入 SonarCloud 的掃描任務。

這邊需要特別注意一點:「Prepare Analysis Configuration」task 必須放在建置步驟之前，而「Run Code Analysis」則要放在建置步驟之後。這是因為 SonarCloud 需要在編譯過程中收集資料。

總的來說，你只少需要三個主要的 Task:

  1. Prepare Analysis Configuration - 準備分析環境(剛才設定的服務連接就在這裡用到)
  2. Build - 執行你的建置(這通常你已經有了)
  3. Run Code Analysis - 執行程式碼分析

來看一個實際的範例:

圖片

執行 Pipeline 並查看結果

設定完成後，儲存並執行你的 Pipeline。

如果一切順利，你會看到 Pipeline 成功執行。在執行的過程中，你可以看到 SonarCloud 的 Task 輸出詳細的分析資訊。

圖片

執行完畢後，最重要的就是倒數第二個連結，那是通往 SonarCloud 分析報告的入口。點進去，你會看到一個完整的程式碼品質儀表板。

在那裡，你會看到:

  • Bugs - 可能的程式錯誤
  • Vulnerabilities - 安全性漏洞
  • Code Smells - 程式碼壞味道
  • Coverage - 測試覆蓋率
  • Duplications - 重複的程式碼
  • Security Hotspots - 需要人工審查的安全性問題

每個問題都會標示嚴重程度，並且附上詳細的說明和修復建議。SonarCloud 甚至會給你的專案一個從 A 到 E 的評級，讓你一眼就能看出專案的整體品質。

更棒的是，它還有「Quality Gate」的概念。你可以設定品質標準，比如「新程式碼不能有 Critical 等級的 bug」、「測試覆蓋率要達到 80%」等等。如果不符合標準，Pipeline 就會失敗，強制你先修好問題才能繼續。

總結:為什麼你應該用 SonarCloud?

說實話，剛開始引入 SonarCloud 的時候，你的專案可能會被標示一大堆問題，看起來很嚇人。但這其實是好事，因為這些問題原本就存在，只是你不知道而已。

把 SonarCloud 整合到 CI/CD Pipeline 中，最大的好處就是:

  1. 持續改善 - 每次 commit 都會被檢查，問題不會累積
  2. 團隊共識 - 大家都能看到相同的品質指標，知道該往哪個方向努力
  3. 降低風險 - 在程式碼進入 production 之前就找出潛在問題
  4. 知識傳承 - 新手可以從 SonarCloud 的建議中學習最佳實踐

而且，一旦設定好，它就會默默地在背景工作，不需要額外的維護成本。就像有個免費的資深工程師在幫你做 code review，豈不是挺好?

程式碼品質不是一蹴可幾的，但有了 SonarCloud 這樣的工具，至少我們有了一個明確的方向和持續改進的機制。而在 Azure DevOps Pipeline 中整合它，就是把這個機制自動化，讓品質管控成為開發流程的一部分，而不是額外的負擔。

試試看吧，你會發現，原來制度化的寫出好的程式碼，並沒有想像中那麼難。

留言

張貼留言

這個網誌中的熱門文章

開啟 teams 中的『會議轉錄(謄寫)』與Copilot會議記錄、摘要功能

作者： -
圖片
在 Teams 中有一個非常好用的功能，可以透過 “謄寫” 把 Teams 的語音會議變成逐字稿，這部分當然是用到語音識別(語音轉文字)的AI技術。 開始謄寫與自動會議紀錄 當啟動一個會議之後，主席可以透過底下這個『開始謄寫』功能來開啟： 這個功能之所以重要，是因為他也是 Teams Copilot 要能夠順利使用的基礎。我們可以透過 Teams Copilot 進行會議的摘要、總結、整理、或是進行會議內容的詢問，而這後面用的則是LLM(大語言模型)的能力： 這功能對於需要參加很多會議的主管、或是在開會遲到的同仁，都是很方便的功能，可以透過詢問Copilot快速地進入會議狀況。 開啟 “謄寫” 功能 然而，這一切的基礎 “謄寫” 功能卻不是每一個機構都有預設開啟，如果你發現你的 “謄寫” 功能是灰色的(無法點選)，就意味著你的組織沒有開啟(或沒有為你開啟)這個功能。 那組織的管理員該如何開啟此功能呢? 很簡單，只需要到 Teams 系統管理中心，點選 『設定和原則』 --> 『會議』： 進入 『會議』 的設定之後，找到『會議錄製』–>『轉錄』 將其『開啟』即可: 如此一來，組織內的同仁就可以順利的使用 Tteams 會議中的語音轉文字(謄寫)功能，也可以使用 Copilot 來查詢會議的內容囉。 Enjoy it~
Read more »

當 Dify 遇上 MCP：打造 AI Agent 從此不再燒腦

作者： -
圖片
以前，要做一個 AI Agent，光是想怎麼讓它跟外部系統溝通，就足以讓人頭痛。 但現在不同了。 Dify 與 MCP：天作之合的組合技 先說說 Dify 。如果你還沒用過它，那真的該好好認識一下。Dify 是一個開源的 LLM 應用開發平台，整合了視覺化的工作流程編輯器、RAG（檢索增強生成）管道、AI Agent 開發能力、模型管理等功能。簡單說，就是把原本複雜的 AI 應用開發，變成拖拖拉拉就能搞定的事情。 然後，另外是 MCP （Model Context Protocol）。這是 Anthropic 推出的協議標準，目的是讓 AI 模型能夠標準地串接各種外部工具、與不同的資料來源溝通。 試想一下，以前當我們想讓 AI 接資料庫、串 API、整合各種企業內五花八門的資訊系統時，每套都要自己刻一個介面。有了 MCP，這些都變成像是標準化的「插頭」，插上去就能用。 當這兩個東西碰在一起，會發生什麼事？ 讓流程無所不能的魔法 有了 MCP 之後，Dify (開發的AI Agent) 能做的事情突然變多了。 更讚的是，我之前做了一個小工具，可以把 Dify 直接串到 LINE OA(官方帳號) 上。現在要設計一個 AI Agent？ 輕鬆到太過美好。 以前要花兩週處理的工作，現在可能半小時就搞定了。 實戰：用 MCP 串接請假系統 直接看個案例。 底下這張圖片就是 Dify 串接 MCP 請假系統進行請假的畫面。看到了什麼？對話介面相當乾淨(下圖右方)，使用者只需要自然地說「我要請假」，AI Agent 就會自動處理剩下的流程，蒐集請假所需要的資料，然後透過MCP呼叫串接好的HR請假系統的 API，完成請假功能。 當然，查詢剩餘請假時數，也是如此。 這背後發生了什麼？AI 透過我們做好的 MCP Tools，呼叫了請假系統的 API，確認你的假別、假期餘額、代理人…等資訊。所有這些複雜的商業邏輯，都被優雅地包裝在 MCP Server 裡面。使用者完全感覺不到複雜性，就像在跟一個很聰明的 AI 聊天助理對談而已。 這就是 MCP 的魅力。 它不只是一個協議，更是一個思維模式的轉變——把複雜的系統整合，變成簡單的行動，讓AI Agent可以在與用戶對話互動中隨時調用。 用 .NET Core 打造你的 MCP Server ...
Read more »

使用LM Studio輕鬆在本地端以API呼叫大語言模型(LLM)

作者： -
圖片
最近上課常被問到，如何在地端環境搭建出大語言模型(LLM)，並且呼叫其API。 一開始我不太理解為何會有這樣的需求(因為在地端自行搭建運行LLM的成本不一定比較低，即便可能比較安全)，但被問多了，也就開始遍尋相關的解決方案，看看有沒有什麼最簡單的方式，可以讓開發人員在地端測試大語言模型? 後來我選擇 LM Studio ，它就是一款設計來運行大型語言模型（LLM）的平台，有個算是挺優雅的整合環境，讓一般 end-user 或開發人員，都可以輕易地在 local 端進行模型的部署和測試。 LM Studio 本身支援多種模型架構和框架，當然，最重要的是，它是免費的。 下載安裝 都很容易，我就不多說。 安裝好之後，你可以看到首頁中已經呈現了許多 Hugging Face上的模型： 這顯然是因為Hugging Face是大部分免費開源模型的集散地。 你可以搜尋自己喜歡的模型，透過LM Studio下載到local之後，就可以直接載入(下圖一)： 隨手設定一下 system prompt(上圖二)，然後，就可以直接對談了。(上圖三) LM Studio會使用你的GPU進行運算(如果有的話)，你會發現，原來有好的設備(GPU)，運行的速度可以如此之快。 Local Server 對於開發人員來說，它還有個超級更友善的功能。 LM Studio本身還提供一個 local server，可以幫你把模型包裹起來讓你直接透過API呼叫該模型的功能，例如： 上圖是我們開啟 LM Studio中 Local Server功能後的結果，你可以透過 localhost 的 1234 port 來呼叫這個被 LM Studio 運行起來的大語言模型。(有沒有發現，我們用的也是 chat/completions API) 透過Postman簡單提供一下 JSON Body: { "model": "LM Studio Community/Meta-Llama-3-8B-Instruct-GGUF", "messages": [ { "role": "system", "content": "你是AI助理，請一律用繁體中...
Read more »

原來使用 .net 寫個 MCP Server 如此簡單

作者： -
圖片
MCP 的重要性與意義 MCP 的重要性在於它建立了一個標準化的架構，讓開發者能夠快速建構出給 AI Agent 呼叫的各種功能。 舉例來說，假設我們希望實現一個 可以透過自然語言對談的請假功能 ，傳統上我們必須建立一個前端 Chat Bot 作為 UI、還得撰寫後端 API、資料驗證邏輯、資料庫存取介面…等，另外還要設計 Chat Bot 的對話邏輯，才能把請假功能整合到Chat Bot的對談訊息中。 但在 MCP 的架構下，這樣的流程可以大幅簡化。 開發者只需要實作幾個「請假功能」的介面（Tool Interface），接著定義好運行這個功能需要輸入哪些參數（例如請假人、開始時間、代理人、事由…etc.），並透過 JSON 來描述這些參數的格式與驗證邏輯。接著，AI Agent 便可以在對話過程中，自動根據對談前後文理解使用者意圖，挑選出適合的Tool來運行，主動發出呼叫的請求。如此一來，大幅簡化了AI Agent開發的難度。(本質上就是 Function Calling 的概念) 而 .net 又把這個難度降低到人人可以開發的程度，底下是一個使用 .net 開發的 請假功能 MCP Server，並且使用 GitHub Copilot來呼叫的例子： 其實我之前用 Semantic Kernel做個類似的範例，只是如今 .net 讓它變得更簡單，而且輕易地可以透過MCP架構讓不同的 MCP Client端呼叫使用。 如何用 .NET 撰寫 MCP Server 要使用 .NET 撰寫 MCP Server 非常簡單，受益於 Microsoft.Extensions.Hosting 和 ModelContextProtocol 套件，我們可以在幾分鐘內輕鬆地實作 MCP Tool 和 MCP Server 。 以下是MCP Server的完整程式碼： using Microsoft . Extensions . DependencyInjection ; using Microsoft . Extensions . Hosting ; using Microsoft . Extensions . Logging ; using ModelContextProtocol . Server ; using System ...
Read more »

敏捷導入的真相

作者： -
圖片
這天 Azure DevOps 課程下課後，又有位學員留下來找我。 事情是這樣的… 他們公司政策規定要導入敏捷和ADO，但上完我的課程後，覺得有點困惑… (我內心OS: 呃? 怎麼會呢? 🤔 你不是應該上完我的課程後豁然開朗的嗎?) 他說，因為公司很多專案還是瀑布式在跑。需求從客戶那邊來的時候，動不動就是三個月、五個月這麼大包的東西。PM 離開技術圈一段時間了，也不知道該怎麼 end-to-end 切出一個迭代(兩周)內可以完成、又有價值的 PBI。 (我一邊聽，一邊想，覺得這是個難題沒錯，但其實最大的挑戰是心理障礙和習慣，因此…) 我跟他說：「其實把需求顆粒度切小，對每個人都有好處。對 PM、對客戶、對開發人員，全是利多。」 他笑的很無奈。 「這道理我可以理解，但我們的開發人員同時身兼好幾個專案，很難專注在某一個案子上。這時候，大家心態上就不想把顆粒度切小，因為怕時時刻刻被盯著要看進度。」 他停頓了一下，接著說：「所以開發人員寧願維持以前那樣一個功能做一個月、兩個月的顆粒度。這樣開發人員可以先去忙別的事情，最後幾天再來趕工。」 聽完，換我沉默想了幾秒。 因為這根本不是技術問題，也不是工具問題。這是整個組織的心態問題。 更深層的，是大家對「敏捷」的誤解。 很多人以為敏捷就是迭代、就是 Scrum、就是看板或站立會議。 但其實，真正的敏捷有一個很明顯的照妖鏡： 需求的顆粒度 。 沒有小的需求顆粒度，就沒有頻繁交付；沒有頻繁交付，就沒有敏捷。 我幾乎可以說，如果團隊無法把需求顆粒度變小，那敏捷導入十之八九是假的。 粗顆粒度的惡性循環 你在 Board(看板) 上看過那種預估要做三、五週的需求卡片嗎？ 「完成訂單管理功能」（預估五週） 「優化報表系統」（預估三週） 「整合第三方金流」（預估兩週） 每次看到這種，我就知道這個團隊有問題。 為什麼？因為一個需求如果要做兩週，在這兩週裡，這張卡片的狀態是什麼？「In Progress」? 但 In Progress 告訴了我們什麼？什麼都沒有。你不知道他做到哪裡了，可能才剛開始，也可能快做完了，也可能卡住了但不好意思說。 更慘的是，開發者在自己的 branch 上悶著頭寫了兩、三週的程式碼。等到要 merge 的時候，衝突、錯誤、邏輯不一致，問題才一個一個冒出來。然後就是...
Read more »