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