一家公司应该保留多少静态分析历史？

Question

假设你在一个非常大的全球性公司工作，拥有大量的所有级别的代码(例如，从嵌入式到移动平台应用程序代码)，那么项目可以持续6个月到5年.

在保存静态分析信息方面，什么是最佳做法?假设缺陷和静态警告之间的可追溯性对组织(例如航空航天、汽车、政府等)很重要。

Answer 1

我不认为你需要保存大量的静态分析信息，如果有的话。但是，要支持这一点，您需要良好的配置管理实践。

首先，您应该定期在源代码存储库中标记代码。考虑标记(git、Subversion、ClearCase -大多数版本控制系统应该支持类似的功能)。通过使用唯一标识符(如版本号或时间戳)标记关键构建，可以将源代码的特定快照与缺陷跟踪数据库或静态分析结果中的条目关联起来。

既然有了标记，就可以将静态分析结果映射到特定的源代码存储库。人们普遍认为，不应该将生成的代码保存在版本控制中。我认为您不应该保留任何可以直接从源代码中生成的内容，其中包括静态分析。但是，为了便于跟踪，您需要能够将从静态分析派生出来的缺陷与导致发现的构建关联起来。

实际上，您可能希望保留一些静态分析结果。例如，外部发布之前的分析结果可以作为正式测试报告的一部分。即使它不是测试报告的一部分，您也可能希望将其保存在项目存档中。您还可以考虑包括静态分析摘要(例如发现的数量、每个源代码行的发现数、按模块划分的发现数量、按临界程度划分的发现数量或按类型划分的发现数量)。

您还可能需要考虑如何管理静态分析工具，特别是当您使用它作为某种正式测试或报告的一部分时。您需要能够考虑该工具的版本以及在给定的代码库版本上执行该工具时使用的配置文件或参数。如果您不管理您的工具版本和配置，就很难为给定的代码库重新生成完全相同的报告。

Answer 2

我发现保持静态分析结果是一个很好的实践。我不一定会对“是哪个构建引入了这个警告”这么感兴趣，因为从您的版本控制系统中应该可以比较容易地看出这一点。此外，如果您对跟踪某个静态分析警告的历史记录感兴趣，那么您可能已经做了一些其他错误的事情，因为它最初出现时没有修复该警告。

我喜欢静态分析结果的主要原因是它能让我看到趋势。例如，我可以看到代码行的数量、问题的数量以及代码覆盖率指标。例如，问题应该与代码行呈线性关系。如果问题的数量比代码行增长得更快，那么可能有人做错了什么。类似地，它有助于建立所需测试覆盖率的基线，并且您可以看到它是否开始下降，如果有人忘记创建测试。

至于你的实际问题是多长时间保存静态分析信息。我想说的是，你应该从项目一开始就把它保留下来，但你不需要把它全部保留下来。例如，SonarQube将是我选择的武器，它会自动修剪它的一些旧快照。(快照是特定构建上的一组静态分析结果。)默认规则在http://docs.sonarqube.org/display/SONAR/History+and+Events中描述，最相关的部分是：

• 1天后，每天只保存一次快照。由事件标记的快照不会被删除。
• 一个月后，每周只保存一次快照。由事件标记的快照不会被删除。
• 一年后，每月只保留一张快照。由事件标记的快照不会被删除。
• 删除所有超过5年的快照，包括由事件标记的快照。

因此，对于当前您看到的所有分析，但明天只有前一天的最后分析是可用的，其他已被删除。在4月底，除最后一次分析外，3月份的所有分析都被删除。等。因此，在不同的时间段里，我们可以选择不同的解决方案。这使您能够有效地保存数年的数据。