2

我目前工作的组织正在进入整个 CMMI 世界，记录一切。我（与其他人一起）被分配了配置经理的头衔。恭喜我没错。

部分职责是定期（他们仍在定义定期，将按季度或按月）进行物理配置审计。这基本上是检查生产中部署的源代码版本与我们认为生产中的源代码版本。

我们的项目是一个用 Java 编写的相对较小的 Web 应用程序。我们使用的文件类型是 java、jsp、xml、属性文件和 sql 包。

我遇到的问题（并且已经表达但似乎被忽略了）是我应该如何物理登录到生产服务器并验证文件版本，即使我可以这样做也会花费大量时间？

文件版本甚至当前不在文件中（即在评论或其他内容中）。建议我们在每个用户可见的屏幕上放置可见的版本号。我也觉得这很荒谬，因为屏幕本身只代表我们维护的代码的一小部分。

我们目前使用的工具是用于我们的 IDE 的 Netbeans 和作为我们的版本控制工具的 Serena Dimensions。

我正在特别寻找有关如何以希望更自动化的方式执行此审核的想法，这将既准确又不耗时。

我目前的想法是在每个文件的顶部添加一个包含该文件版本号的注释，一个在创建生产构建时运行的脚本以创建 XML 文件或包含每个文件的文件名和版本文件的类似文件构建中的文件。然后，当我需要进行审计时，我会去生产服务器获取带有信息的 xml 文件，并以编程方式将其与我们认为在生产中的内容进行比较，然后输出报告。

任何更好的想法。我知道这必须已经完成，并且对我来说似乎很疯狂，因为我没有找到任何其他资源。

4

3 回答 3

4

您可以计算生产服务器上源文件的 SHA1 哈希值，并将该哈希值与存储在源代码控制中的版本进行比较。如果您可以在源代码管理中找到相同的哈希，那么您就知道生产中的版本。如果您在源代码控制中找不到相同的哈希值，则说明生产中有未跟踪的修改，您的新职位是合理的。:)

于 2008-10-28T21:52:18.960 回答
3

典型的陷入 CMMI 陷阱的组织试图做任何事情都做得过火。如果我可以提出任何建议，那就是从小处着手，只做你需要的。因此，请考虑您之前在 CM 领域可能遇到的任何问题。

CMMI 描述了组织应该做什么，但如何由您决定。CMMI 规范，第2 章非常值得一读——它描述了规范的必需、预期和信息性组件——基本上，目标是必需的，实践是预期的，其他一切都是信息性的。这意味着只有一小部分规范是 CMMI 评估员可以直接要求的——目标。在实践层面，既可以采用所描述的实践，也可以采用可接受的替代方法。

在配置审计的情况下，目标 SG3 是“建立和维护基线的完整性”。SP3.2 说“执行配置审计以维护配置基线的完整性。” 这里没有说明这些操作的频率或可能需要多长时间。

在我以前的组织中，FCA/PCA 通常只作为产品发布过程的一部分完成，我们使用 ClearCase 作为版本控制工具，并在代码库中应用标签来定义基线。我们在所有源文件中都没有版本号，在所有产品屏幕上也没有版本号 - CM 活动正在做正确的事情并得到审计的支持，这在任何 CMMI 评估中都不是问题. 我们可以使用标签之间的差异来查看哪些文件发生了更改，执行差异来查看实际的代码更改。该过程的一个重要部分是能够将这些更改链接回需求/错误报告/引发更改的任何原因。

我们的审计确实使用脚本来自动化流程，但这些是内部开发的特定于 ClearCase 的脚本 - 基本上它们会列出所有文件、它们在 CM 系统中的版本以及它们所属的基线/配置项。

于 2008-10-28T22:22:43.640 回答
0

您不能为此使用源代码管理吗？如果您部署一个版本并使用该部署标记您的源代码控制，那么您可以根据源代码控制系统进行验证

于 2008-10-28T21:53:49.407 回答