静态分析警告是否会使CI构建失败？

Question

我们的团队正在研究项目中静态分析的各种选项，并且由于静态分析的警告，我们对是否希望我们的持续集成构建失败提出了不同意见。

反对构建失败的论点是规则经常有例外，并且试图解决它们只是为了使构建成功会降低生产力。更好的方法是使用构建生成报告，并定期将开发人员的时间用于解决报告的问题。

相反的论点是，如果不立即解决错误，技术债务很容易积累。此外，如果在引入潜在错误时构建失败，则修复它所需的时间会减少。

你有什么想法？

Answer 1

就个人而言，我宁愿看到构建失败。虽然某些警告是误报，但可以使用SuppressMessageAttribute使用Justification排除警告。执行此操作时，您确信开发人员会对每个警告进行评估，并且不会发生任何事情。

Answer 2

构建失败可能是一个好主意，但这不一定是一个绝对的黑白决定。

如果超出新的静态分析错误的阈值，

Hudson会让您失败。因此，您可以说“如果引入了1个新故障，则将构建标记为不稳定;如果引入了5个新故障，则将构建标记为失败”。

这是Hudson可用的各种分析插件中的内容。

Answer 3

我通常会在静态分析错误上构建失败（不仅是CI构建，而且还是在提交之前在开发人员计算机上运行的构建，并且我使用可以包含在IDE中的工具） 。

如果你不这样做，我的经验是错误没有得到修复，实际上永远不会，因为如果你认为错误是化妆品（或者你不允许提交，对吧？），总会有更重要的事情。如果存在合理的异常，大多数工具都允许排除代码片段（使用自定义注释或排除过滤器等内容）。

如果要使用静态分析，请正确执行，在问题发生时解决问题，不要让错误进一步传播到系统中。允许这种情况发生的过程is wrong：

  

让我们为美式风格做点什么：你烧，我会刮。 --W。爱德华兹戴明。

Answer 4

艰难的电话，没有一个好的全球答案。我想同意之前的两篇帖子并说是，但我的静态分析第二定律说，缺陷会聚集在软件工程过程最严重的组织部分。一个必然结果是，那些被迫匆忙改变代码以避免警告消失的工程师，最有可能在他们这样做时引入新问题;我已经看到很多这样的错误令人沮丧。我认为在代码之外进行假阳性标记是更好的软件工程，例如Coverity和Klocwork，并根据它进行执行。
毫无疑问，关于追踪这些新缺陷的主要观点，尽可能大声地，及时花费时间来避免技术债务，都是很好的想法。

Answer 5

除了错误失败之外，您还需要一个流程来调查警告，并确定其中一些警告是否成为错误。