持續交付和 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 傑蛙中國
歡迎轉載，但轉載請註明作者與出處。謝謝！