SonarQube 解決了代碼追蹤問題

經過不斷分析代碼以瞭解潛在的質量問題，開源的 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 的人有頗有幫助。

 

原文來自： https://www.linuxprobe.com/sonarqubedevops.html