我一直在挖掘Sonar最佳實踐。共識似乎是Sonar每天或每週只能發射一次，例如在夜晚。但是，如果使用Jenkins這樣的CI服務器呢？ Jenkins以每個SVN提交爲基礎，運行單元測試，部署到分段環境，運行Selenium測試等等。按照我的理解，如果Sonar每天/每週啓動一次，所有這些附加信息都會丟失。很可能所有團隊的代碼問題和失敗的測試都在下週或週末結束。聲納可能在週日晚上或每晚都運行。該應用程序是預先構建和測試的，然後根據該信息執行聲吶分析。很可能所有測試都通過了，存儲庫中沒有任何重大代碼問題，QA團隊錯誤地認爲沒有任何問題，因爲所有Sonar報告都顯示爲綠色。然而，在白天/週期間，這個項目可能已經完全混亂，破損等等，但從未在Sonar報告中顯示:)僅需每天或每週發射一次Sonar就足夠了嗎？
我是否在這裏丟失了某些東西，或者Sonar實際上是否會被執行每一次提交，或至少一次一小時？
這一切都在你的需要和dependes你的團隊的速度開發新代碼，測試並將新功能集成到項目中。
如果你有一個網絡時間框的衝刺，可能是在週末，星期一開始的版本是穩定的，因此沒有bug或只有一些錯誤。如果您的衝刺時間框是一週，我會至少每天推薦一次，這樣您可以在運行單元測試等時發現缺陷，從而爲您的項目質量提供良好的實際情況。
我會推薦這些做法：
這些是我在項目中使用的實踐，但您必須仔細研究您的需求，因爲工具（Sonar）會幫助您獲得關於項目質量的信息，因此，您的架構，你的團隊和你的工程實踐。
Sonar收集的大部分數據是靜態分析信息（複雜性，代碼風格違規等），除非代碼被重構，否則這些信息在構建和構建時不會有太大變化，所以應該足以運行一次一天。還要考慮到聲吶分析會增加您的構建執行時間 - 在我的工作中，它可以爲構建添加2到3分鐘，只需要很長時間就可以編譯和測試。
如果您希望爲每個CI構建收集代碼覆蓋率和測試結果，您可以在Jenkins中做到這一點，並使用Jenkins作爲構建健康狀況的早期預警系統，讓Sonar能夠對代碼質量和可維護性進行更長期的分析。
，您仍然可以態勢代碼覆蓋測試結果聲納，你在你的問題中提到，你是不會有它的每一個CI構建
可以在每次提交時用cobertura執行單元測試，並每天晚上運行一次Sonar分析。不過，我認爲這打破了使用Sonar作爲您的集中質量存儲庫的重點。如果cobertura在沒有Sonar的情況下執行，那麼您將開始在兩個地方進行質量測量：Jenkins和Sonar。 QA有人會看你的聲納指標，並說「這很好，但你最近怎麼樣？」然後，您必須開始挖掘不屬於聲納的其他_other_測試報告，並且您發現您在項目中的表現並不好，因爲質量...... – user1340582
這是事實，它取決於您對質量的定義 - 在根據我的經驗，很難有一個地方可以查看影響產品質量的所有因素。因此，我使用CI系統向我發出即時質量「破損」（編譯失敗，測試失敗，代碼覆蓋率降至閾值以下等等）的警告，並讓Sonar保持更長期的趨勢。您仍然可以在您的問題中提到Sonar中的趨勢代碼覆蓋率和測試結果，但對於每個CI構建，您都不會擁有它。 –
每天一次運行聲吶不應被視爲「最佳做法」。考慮到可用的硬件和質量測量的質量，它可能是目前最好的，但正如你所說的，在CI環境中，每一次提交都需要反饋（實際上它也應該在提交過程中提供，就像你可以使用Smalltalk & MOOSE在每個方法保存）。我目前正在處理的部分的代碼複雜度和測試覆蓋率變化是我喜歡的粒度小於每天一次的一些可視化/度量。
Sonar爲您的構建增加了很多時間是一個實現問題，而非基礎問題，可以通過多種不同的方式解決：緩存信息，慢速和快速測量之間的分離，模塊拆分，異步運行等。
好的，謝謝。我上面的其他評論也部分針對你的答案，因爲人們會/應該只有一個質量報告存儲庫。 Jenkins cobertura報告可能表明存在巨大質量問題，但從未在Sonar中顯示。我想知道，我們當然可以用單元測試報告來執行Sonar，但是在每次提交時都沒有代碼分析，並且每天甚至每週執行一次_both_測試報告和代碼分析報告。人們將不得不維護獨立的聲納執行配置，但這可能是好的... – user1340582
聲納缺乏質量來顯示有關測試和代碼質量的信息。事實上，Sonar只是一個嘗試使用第三方工具收集信息的工具，如Web界面中的Cobertura，PMD，Checkstyle等。它可能比現在好得多。 – gdfbarbosa