持續交付和 DevOps 是眾所周知的，並在當今廣泛傳播的做法。人們普遍認為，組建優秀的團隊，首先確定共同的目標，然後選擇和整合最適合的工具是至關重要的。通常，這是一個輕量級工具的集合，整合在一起構建了持續交付流水線，並支援 DevOps。在本文中，我們放大了整個流程的一個重要部分，即通常被稱為連續檢查的部分，其中包括檢查程式碼並注入質量關卡，並顯示質量關卡之後如何上傳符合要求的工件。包括 Jenkins，SonarQube 和 Artifactory 在內的 DevOps 工具。

如何使用

質量關卡不能在事後注入，而應該從一開始就是過程和產品的一部分。作為一種常用的良好做法，強烈建議儘快檢查程式碼並使結果可見。對於 SonarQube 來說，這是一個不錯的選擇。但 SonarQube 不僅僅是單獨執行，而是整合在交付流水線中。作為流水線的一部分，程式碼被檢查，並且只有當代碼根據定義的要求好時，換句話說：符合質量關卡，構建的工件才被上傳到二進位制儲存庫管理器。

我們來考慮下面的情況。其中一個繁忙的開發人員必須修復程式碼，並檢查中央版本控制系統的變化。這一天是漫長的，開發人員並沒有檢查本地的程式碼質量。幸運的是，構建引擎 Jenkins 作為一個單一的例項，通過其原生的流水線功能來實現交付流水線，碰巧，SonarQube 支援 Jenkins 流水線。

該更改觸發了一個新的流水線執行。不好了！構建流水線中斷，流水線不會往下進行。在下面的圖片中，你會看到流水線沒有通過定義好的的質量關卡。(視覺化是由 Jenkins 的 Blue Ocean 外掛完成的)

SonarQube 檢查

根本問題是什麼？開啟 SonarQube Web 應用程式並深入查詢。在 Java 程式碼中，顯然一個字串文字不應該放在右側。

在小組會議中，決定將其定義為 Blocker，並相應地配置 SonarQube。此外，SonarQube 質量關卡是為了中斷不符合質量關卡的任何構建，如果構建被阻攔。檢視程式碼，下面的例項證明， SonarQube 是正確的，這個程式碼片段就是被攔截的片段。

我們不詳細討論所有使用過的工具，而且還包括完整的 Jenkins 構建工作將不在範圍之內。但是這裡有一段關於程式碼檢查的部分，是在 Jenkins 流水線 DSL 中定義的：

SonarQube 質量關卡

作為 Jenkins 流水線階段的一部分，SonarQube 被配置為執行中並檢查程式碼。但這只是第一部分，因為我們現在也想新增質量關卡來過濾構建。如果某個階段正在執行，流水線暫停，直到通過質量關卡，具體來說，waitForQualityGate 步驟將暫停流水線，直到 SonarQube 分析完成並返回質量關卡狀態。如果沒有通過質量關卡，構建就會中斷。

由於都在一個敏捷團隊中工作，下一個同事會及時解決這個問題。在修復後的程式碼提交之後，構建流水線再次執行。

流水線被成功處理，包括 SonarQube 質量關卡，最後一步，測試過的工件被部署到 Artifactory。如何上傳工件有兩種不同的靈活方式，我們在這裡使用的是使用上傳 Rest 請求來實際收集和上傳在流水線開始時構建的工件。元資料也被髮布到 Artifactory，因為它是重要的上下文，因此可以為工件新增有價值的標籤以供進一步處理。

現在讓我們看看是否成功將二進位制檔案部署到 Artifactory。作為上下文資訊的一部分，還可以參考 Jenkins 構建作業來獲得更好的可追溯性。

總結

在本文中，我們發現了將 Jenkins 與 SonarQube 整合的技巧和訣竅，如何使用 Jenkins 流水線 DSL 定義 Jenkins 階段，如何使用 Jenkins Blue Ocean 將這些階段視覺化，以及如何將工件部署到我們的二進位制儲存庫管理器 Artifactory 中的。

原文連結：https://jenkins.io/blog/2017/04/18/continuousdelivery-devops-sonarqube/

譯者：劉志偉，JFrog 傑蛙中國

歡迎轉載，但轉載請註明作者與出處。謝謝！