仅每天或每周发射一次声纳就足够了吗？

Question

我一直在挖掘Sonar最佳实践。共识似乎是Sonar每天或每周只发布一次，例如在夜间。但是，如果使用像詹金斯这样的CI服务器呢？ Jenkins构建于每个SVN提交，运行单元测试，部署到登台环境，运行Selenium测试等等。我理解它的方式，如果Sonar每天只启动一次，所有这些额外信息都会丢失。很可能所有团队的代码问题和失败的测试都已在下午或本周结束时得到解决。声纳可能在周日晚上或每晚都会运行。该应用程序已预先构建并经过测试，然后根据该信息执行声纳分析。很可能所有测试都通过，存储库中没有遗留任何重大代码问题，并且QA团队错误地认为没有问题，因为所有Sonar报告都显示为绿色。但是，在白天/周期间，项目可能已经完全混乱了破碎的构建等，但是从未在Sonar报告中显示：）

我在这里遗漏了什么，或者Sonar实际上是应该在每次提交时执行，还是至少每小时执行一次？

Answer 1

这一切都取决于您的需求和团队的速度，以开发新代码，测试并将新功能集成到项目中。

如果你有一个带有网络时间框的sprint，可能就是在周末，那个星期一开始的版本是稳定的，因此没有bug，或只有一些bug。如果您的冲刺时间框是一周，我建议至少每天一次，这样您就可以获得运行单元测试的缺陷等等，从而为您的项目质量提供良好的现实。

我会推荐这些做法：

1. 使用像Cobertura这样的代码覆盖率，每天至少运行一次单元测试;
2. 使用PMD，checkstyle等代码分析。如果可能，请创建适用于您的体系结构的自己的规则，从而在质量方面为您的项目创造更多价值。
3. 考虑一下Sprint的时间框，为声纳中的构建选择一个频率，并安排一个仅在您真正需要时运行它的cron作业（因为它非常耗时）。

这些是我在项目中使用的实践，但您必须仔细查看您的需求，因为该工具（Sonar）将帮助您获得有关项目质量的信息，因此，您的架构，团队和你的工程实践。

Answer 2

Sonar收集的大多数数据都是静态分析信息（复杂性，代码样式违规等），除非代码被重构，否则从构建到构建不会有太大变化，所以它应该足以运行一次天。还要考虑Sonar分析会增加你的构建执行时间 - 在我的工作中，它可以为构建添加2或3分钟，只需要花费很长时间来编译和测试。

如果您想为每个CI构建收集代码覆盖率和测试结果，您可以在Jenkins中执行此操作，并使用Jenkins作为构建运行状况的早期预警系统，让Sonar可以对整体代码质量和可维护性进行更长期的分析。

如您在问题中所提到的，您仍然可以在Sonar中趋势代码覆盖率和测试结果，您不会为每个CI构建提供它

Answer 3

每天/每周运行一次声纳不应被视为最佳实践＆＃39;。考虑到可用的硬件和质量测量质量，它可能是目前最好的，但正如你所说，在CI环境中，你需要每次提交反馈（实际上也应该在提交内部，就像你可以使用Smalltalk＆amp;每个方法保存MOOSE）。我目前正在处理的部件的代码复杂性和测试覆盖范围变化是我喜欢的一些可视化/测量，其粒度小于每天一次。

Sonar为你的构建增加了很多时间是一个实现问题，而不是一个基础，并且可以通过多种不同的方式解决：缓存信息，在慢速和快速测量之间拆分，拆分模块，异步运行，等。