.NET Walker

關於 Azure DevOps 中的 YAML Pipeline 最近在上課上到 Azure DevOps Pipeline 的時候，發現有些技術人員對 ADO 的 YAML Pipeline 有個小小的誤會。 很多人以為，只要是 Azure DevOps 的 YAML Pipeline，就一定要放在 repo root 底下，然後檔名一定要叫： azure-pipelines.yml 其實，不是的。 這個檔名只是 Azure DevOps 預設最容易被偵測到的慣例，並不是限制。 換句話說，你的 repo 裡可以有： /azure-pipelines.yml 也可以有： /pipelines/ci.yml /pipelines/deploy-dev.yml /pipelines/deploy-prod.yml /pipelines/security-scan.yml /.azuredevops/agentic-dev.yml 真正的重點不是檔名，而是： Azure DevOps 裡的 Pipeline Definition 必須指向 repo 中的某一個 YAML 檔案 也就是說，Pipeline 不是靠檔名自動決定要跑哪一份 YAML，而是 Azure DevOps 裡面那條 Pipeline 本身記住了它要使用哪一個 YAML file path。 建立新的 YAML Pipeline，並指定特定的 yml 檔案 假設你的 repo 裡已經有一份 YAML： /pipelines/ci.yml 那麼你可以這樣建立一條新的 Pipeline，連結到既有的 yaml 檔案，作法是在新增 yml pipeline 的時候，選擇 Select an existing YAML file： 接著選擇你的程式碼中的 yml 來源即可，這樣一來，你就在 Azure DevOps 裡建立了一條新的 Pipeline，而這條 Pipeline 使用的 YAML 內容，就是： /pipelines/ci.yml 一個 repo 可以有多個 YAML Pipeline 這也是另一個常見誤會。 很多人以為一個 repo 只能有一個 YAML Pipeline。 當然不是。 當你知道可以在建立 Yaml Pipeline 的時候，指...

程式碼品質，絕對是每個專業開發團隊都會遇到的課題。 你知道的，當系統上線後，突然收到資安通報說發現了安全性漏洞，需要緊急修補。更糟的是，這個漏洞在開發階段就可以避免，只是當時沒人發現。然後你開始翻 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 DevOp...