通過不斷分析代碼以了解潛在的質量問題，開源的 SonarQube 項目支持了 DevOps 的“盡早發布和經常發布” 的思維模式。

越來越多的組織正在實施 DevOps 以便在通過中間開發和測試環境以后更快更好的將新代碼引入到生產環境。雖然版本控制、持續集成和部署以及自動化測試都屬于 DevOps 的范疇，但仍然存在一個關鍵問題：組織如何量化代碼質量，而不僅僅是部署的速度？

SonarQube 是用來填補這個空隙的一種選擇。它是一個開源平臺，通過代碼的自動化靜態分析不斷的檢查代碼質量。 SonarQube 支持 20 多種語言的分析，并在各種類型的項目中輸出和存儲問題。

SonarQube 同時也提供了一個可同時維護和管理不同項目、不同代碼的集中的環境。可以為每個項目定制規則。持續的檢查和分析代碼的健康軌跡。

SonarQube 還可以集成到可持續集成和開發（CI/CD）流程中，協助和自動確定代碼是否為生產環境做好了準備的過程。

它可以衡量什么

開箱即用，SonarQube 可以測量的關鍵指標，包括代碼錯誤、代碼異味code smells、安全漏洞和重復的代碼。

• 代碼錯誤 是代碼中的一部分不正確或無法正常運行、可能會導致錯誤的結果，是指那些在代碼發布到生產環境之前應該被修復的明顯的錯誤。
• 代碼異味 不同于代碼錯誤，被檢測到的代碼是可能能正確執行并符合預期。然而，它不容易被修復，也不能被單元測試覆蓋，卻可能會導致一些未知的錯誤，或是一些其它的問題。從長期的可維護性來講，立即修復代碼異味是明智之舉。通常在編寫代碼的時候，代碼異味并不容易被發現，而 SonarQube 的靜態分析是一種發現它們的很好的方式。
• 安全漏洞 正如聽起來的一樣：指的是現在的代碼中可能存在的安全問題的缺陷。這些缺陷應該立即修復來防止黑客利用它們。
• 重復的代碼 也和聽起來的一樣：指的是源代碼中重復的部分。代碼重復在軟件設計中是一種很不好的做法。總的來說，如果對一部分代碼進行更改而另一部分沒有，則會導致一些維護性的問題。例如，識別重復的代碼可以很容易的將重復的代碼打包成一個庫來重復的使用。

可自定義的選項

因為它是開源的，所以 SonarQube 鼓勵用戶開發和提供可定制的選項。目前有超過 60 個插件 可用于增強 SonarQube 開箱即用的分析功能。

大多數的插件是為了增加 SonarQube 可以分析的編程語言的數量。另一些插件可以分析一些額外的指標甚至包括一些顯示的儀表盤視圖。實際上，如果組織需要檢查一些自定義指標，或是想要在自己的儀表盤和以特定的方式查看分析數據，或使用 SonarQube 不支持的編程語言，則可能存在一些自定義的選項可以使用。如果你想要的功能并不支持，SonarQube 源碼的開放也為你自己開發新的功能提供了可能性。

用戶還可以定制適用于每種特定編程語言分析器的規則。通過 SonarQube 用戶界面，可以按語言和按項目選擇和取消規則。這些為特定的項目指定的規則，可以很好的在一個集中的位置維護所有的數據和配置。

為什么它那么重要

SonarQube 為組織提供了一個集中的位置來管理和跟蹤多個項目代碼中的問題。它還可以把持續的檢查與質量門限相結合。一旦項目分析過一次以后，更進一步的分析會參考軟件***的修改來更新原始的統計信息，以反映***的變化。這些跟蹤可以讓用戶看到問題解決的程度和速度。這與 “盡早發布并經常發布”不謀而合。

另外，SonarQube 可使用 可持續集成流程，比如像 Hudson 和 Jenkins 這樣的工具。這個質量門限可以很好的反映代碼的整體運行狀況，并且通過 Jenkins 等集成工具，在發布代碼到生產環境時擔任一個重要的角色。

本著 DevOps 的精神， SonarQube 可以量化代碼質量，來達到組織內部的要求。為了加快代碼生產和發布的周期，組織必須意識到它們自己的技術債務和軟件問題。通過發現這些信息， SonarQube 可以幫助組織更快的生成高質量的軟件。

想要了解更多嗎？

SonarQube 基于 GUN 通用公共許可證發布，它的源碼可以在 GitHub 上查看。越來越多的用戶對 SonarQube 的特性和功能感興趣。 Twitter 和 Google 上有活躍的社區。這些社區以及 SonarQube 博客 對任何有興趣開始和使用 SonarQube 的人有很有幫助。