我一直在深入研究 Sonar 的最佳实践。共识似乎是声纳每天或每周只发射一次，例如在夜间。但是，如果使用 Jenkins 之类的 CI 服务器会怎样？Jenkins 构建在每个 SVN 提交上，运行单元测试，部署到登台环境，运行 Selenium 测试等。按照我的理解，如果 Sonar 每天/每周只启动一次，所有这些附加信息都会丢失。很可能所有团队的代码问题和失败的测试都在下午或周末得到解决。声纳可能在周日晚上或每晚运行。该应用程序是预先构建和测试的，然后基于该信息执行声纳分析。很可能所有测试都通过了，存储库中没有留下任何主要的代码问题，并且 QA 团队错误地认为没有问题，因为所有 Sonar 报告都显示为绿色。但是，在白天/一周内，该项目可能会因构建损坏等而一团糟，但从未在声纳报告中显示:)
我在这里遗漏了什么，还是应该在每次提交时实际执行 Sonar，或者至少每小时执行一次？
这完全取决于您的需求和团队开发新代码、测试新功能并将新功能集成到项目中的速度。
如果你有一个带有时间盒的网络冲刺，可能是在周末，周一开始的版本是稳定的，因此没有错误，或者只有几个错误。如果您的 sprint 时间框是一周，我强烈建议您每天至少一次，这样您就可以在运行单元测试等时发现缺陷，从而为您的项目质量提供良好的现实。
我会推荐这些做法：
这些是我在项目中使用的实践，但您必须密切关注您的需求，因为该工具 (Sonar) 旨在帮助您了解有关项目质量的信息，从而了解您的架构、团队和工程实践.
Sonar 收集的大部分数据是静态分析信息（复杂性、代码风格违规等），除非代码被重构，否则在构建之间不会有太大变化，因此每天运行一次就足够了。还要考虑 Sonar 分析会增加您的构建执行时间 - 在我的工作中，它可以为构建增加 2 或 3 分钟，而首先编译和测试只需要很长时间。
如果您想为每个 CI 构建收集代码覆盖率和测试结果，您可以在 Jenkins 中执行此操作，并将 Jenkins 用作构建健康状况的早期预警系统，让 Sonar 对整体代码质量和可维护性进行更长期的分析。
正如您在问题中提到的那样，您仍然可以在 Sonar 中对代码覆盖率和测试结果进行趋势分析，只是不会为每个 CI 构建提供它
每天/每周运行一次声纳不应被视为“最佳实践”。考虑到可用的硬件和质量测量的质量，这可能是目前最好的，但正如你所说，在 CI 环境中，每次提交都需要反馈（实际上也应该在提交中包含它，就像使用 Smalltalk 和 MOOSE 一样在每个方法保存）。我目前正在处理的部分的代码复杂性和测试覆盖率变化是我喜欢的一些可视化/测量，其粒度比每天一次要小得多。
Sonar 为您的构建增加了很多时间是一个实现问题，而不是基本问题，并且可以通过多种不同的方式来解决：缓存信息、在慢速和快速测量之间分割、在模块中分割、异步运行等。