SonarQube - 如何将最后的成功分析指定为泄漏期

Question

我们正在使用SonarQube 5.5(迄今为止最新).

我们的项目包含许多遗留代码,这些代码无法通过我们所需的质量门,因此我们决定忽略已经存在的技术债务,但要严格对待新的变更.

因此,我们正在享受泄漏概念和默认质量门,仅考虑新的变化.

我们使用持续集成和持续交付,因此我们为每个CI构建运行SonarQube分析,以便能够立即向开发人员反馈他们的更改是否未通过质量门,因此问题不会留到sprint结束或累积新的技术债务.

我们将Leak Period设置为previous_version,因为我们每次运行都会增加版本号,但据我所知,在我们的情况下,它可以设置为previous_analysis并具有相同的效果.

这种方法的问题在于下一个好的提交将清除项目的状态(绿色,是红色),因为对最后一次提交的分析将通过质量门.虽然代码已包含先前提交中引入的问题.

如果将"泄漏期间"设置为固定日期\版本(自定义日期或A版本选项),则将对累积提交进行分析,并且单个"错误"提交可能会被忽视,从而导致周期后期出现问题.所以它不满足"直接"要求.想象一下,在一个固定的日期\版本之后,有5个相同大小的提交 - 4个来自"好"的开发人员跟随TDD所以100%覆盖率,1个来自"坏"的人,其变化覆盖率为0%.平均而言,它将通过默认条件"新代码的覆盖率不低于80%",但实际上我们希望尽快向这些"坏"人提供反馈,以便他们改进他们的实践.

如果将"泄漏期间"设置为滚动分析前的天数,则自上次"错误"提交后经过此天数后,门的状态将立即清除,而代码中仍可能存在问题.

我们需要能够分析单个提交(类似于SQ中的"previous_version"泄漏期选项).但是如果最后一次提交通过QG而前一次提交失败,我们应该一起分析它们以查看最后一次提交是否实际修复了前一次提交的问题,以便整个项目可以被视为已通过.

因此,实质上我们应该分析自上次成功分析以来的所有提交

泄漏期没有这样的选择.有没有其他方法来实现这一目标？

Answer 1

要跟踪开发人员的代码覆盖率，您可以执行以下操作：

• 配置质量门以获得预期覆盖率（原始值）和新代码的预期覆盖率（泄漏期）
• 利用您可以配置的 C# 规则InsufficientLineCoverage和InsufficientBranchCoverage