【发布时间】：2016-05-10 17:22:20
【问题描述】：
我们正在使用 SonarQube 5.5（最新版本）。
我们的项目包含许多无法通过我们期望的质量门的遗留代码，因此我们决定忽略已经存在的技术债务，但对新的更改保持严格。
所以我们享受Leak 概念和只考虑新变化的默认质量门。
我们使用持续集成和持续交付，因此我们对每个 CI 构建运行 SonarQube 分析，以便能够立即向开发人员提供反馈，无论他们的更改是否未能通过质量门，因此问题不会留到 sprint 结束或新的累积的技术债务。
我们将 Leak Period 设置为 previous_version，因为我们每次运行都会增加版本号，但据我了解，在我们的案例中，它可以设置为 previous_analysis，效果相同.
这种方法的问题是，下一次好的提交将清除项目的状态（绿色，为红色），因为最后一次提交的分析将通过质量门。虽然代码已经包含了之前提交中引入的问题。
如果 Leak Period 设置为固定日期\版本（自定义日期或版本选项），将对累积提交和个别“坏”的提交运行分析提交可能会在不被注意的情况下挤过，从而导致周期后期出现问题。所以它不满足“即时”的要求。 想象一下，在一个固定的日期\版本之后，有 5 个相同大小的提交 - 4 个来自遵循 TDD 的“好”开发人员，覆盖率为 100%，1 个来自“坏”的人，其更改的覆盖率为 0%。平均而言，它会通过默认条件“新代码的覆盖率不低于 80%”，但实际上我们希望尽快将反馈给这些“坏人”，以便他们改进他们的做法。
如果 Leak Period 设置为滚动分析前的天数，自上次“错误”提交后经过此天数后，Gate 的状态将立即清除，而问题仍可能在代码中。
我们需要能够分析单个提交（类似于 SQ 中的“previous_version”Leak Period 选项）。 但是如果最后一次提交通过了QG，而前一次失败了，我们应该一起分析，看看最后一次提交是否真的修复了前一次的问题，这样整个项目就可以认为是通过了。
所以，本质上我们应该分析自上次成功分析
以来的所有提交Leak Period 没有这样的选项。 有没有其他方法可以做到这一点？
【问题讨论】：
-
我不明白为什么“A 版本”或“A 日期”不起作用。在 SonarSource，我们正在对每次提交进行分析，并且泄漏设置为“previous_version”（因为我们不会在每次提交时增加版本）：效果很好。您不能错过在泄漏期间（无论是什么期间）发生的错误提交中引入的问题，因为问题已被跟踪。所以我不太明白你的问题。
-
@Fabrice-SonarSourceTeam，很抱歉没有更好地解释这一点。想象一下，在一个固定的日期\版本之后，有 5 个相同大小的提交 - 4 个来自遵循 TDD 的“好”开发人员，覆盖率为 100%，1 个来自“坏”的人，其更改的覆盖率为 0%。平均而言，它会通过默认条件“新代码的覆盖率不低于 80%”，但实际上我们希望尽快将反馈给这些“坏人”，以便他们改进他们的做法。
-
@Fabrice-SonarSourceTeam，另外，恕我直言，如果代码通过了 SonarQube 中的质量门，则逻辑上可以认为是“良好”，因此可以将泄漏期重置为此版本的代码。在您的情况下，如果我理解正确，您仅在您对该版本感到满意时才手动增加版本，不仅从 SonarQube 的角度来看，而且在进行了一些其他检查（版本的完整性？，在管道中通过的测试？等），所以只有你增加版本并重置泄漏期。但是……为什么要分析之前已经分析过并被认为“好”的代码？
-
@Ivan 最好通过代码审查来帮助开发人员提高代码覆盖率
-
不幸的是从未解决过这个问题。
标签： continuous-integration sonarqube continuous-delivery software-quality