我们正在使用SonarQube 5.5（迄今为止最新）。
我们的项目包含许多传统代码，这些代码无法通过我们想要的质量门，所以我们决定忽略已经存在的技术债务，但要严格对新的变化。< / p>
因此，我们正在享受Leak概念和默认质量门，仅考虑新的变化。
我们使用持续集成和持续交付，因此我们对每个CI构建运行SonarQube分析，以便能够立即向开发人员反馈他们的更改是否未通过质量门，因此问题不会留到sprint结束，或者新的累积技术债务。
我们将Leak Period设置为 previous_version ，因为我们每次运行都会增加版本号，但据我所知，在我们的情况下可以设置为 previous_analysis ，效果相同
这种方法的问题在于下一个好的提交将清除项目的状态（绿色，是红色），因为对最后一次提交的分析将通过质量门。虽然代码已经包含先前提交中引入的问题。
如果将“泄漏期间”设置为固定日期\版本（自定义日期或 A版本选项），则会针对累计提交和个别＆＃34运行分析坏的＃34;提交可能会被忽视，导致周期后期出现问题。所以它并不能满足＆＃34;立即＆＃34;需求。 想象一下，在固定日期\版本之后，有5个相同大小的提交 - 4个来自＆＃34;好＆＃34;开发人员遵循TDD，100％覆盖率，1个来自＆＃34;坏＆＃34;变化覆盖率为0％的人。平均而言，它将通过默认条件＆＃34;新代码的覆盖率不低于80％＆＃34;，但实际上我们希望向这样的＆＃34;坏＆＃34;提供反馈。伙计们尽快改善他们的做法。
如果泄漏期间设置为滚动分析前的天数，则自上次＆＃34;坏＆＃34;以来经过此天数后，门的状态将立即清除。提交，而问题仍然存在于代码中。
我们需要能够分析单个提交（类似于＆＃34; previous_version＆＃34; SQ中的泄漏期选项）。 但是如果最后一次提交通过QG而前一次提交失败，我们应该一起分析它们以查看最后一次提交是否实际修复了前一次提交的问题，以便整个项目可以被视为已通过。
因此，实质上我们应该分析自上次成功分析
以来的所有提交泄漏期没有这样的选择。 还有其他方法可以达到这个目的吗？
答案 0 :(得分：-1)
要跟踪开发人员的代码覆盖率，您可以执行以下操作：