执行 CMMI 物理配置审核的最佳方法？
我目前工作的组织正在进入记录一切的整个 CMMI 世界。 我（和另外一个人）被分配了配置经理的头衔。 恭喜我没错。
部分职责是定期执行物理配置审核（他们仍在定义定期，将按季度或每月）。 这基本上是对生产中部署的源代码版本与我们认为是生产中的源代码版本的检查。
我们的项目是一个用 Java 编写的相对较小的 Web 应用程序。 我们使用的文件类型是 java、jsp、xml、属性文件和 sql 包。
我遇到的问题（并且已经表达过，但似乎被忽略了）是我应该如何物理登录到生产服务器并验证文件版本，即使我可以，它也会花费大量时间？
文件版本当前甚至不在文件中（即在注释或其他内容中）。 建议我们在每个用户也可见的屏幕上放置可见的版本号。 我也认为这很荒谬，因为屏幕本身只代表我们维护的代码的一小部分。
我们当前使用的工具是用于 IDE 的 Netbeans 和作为版本控制工具的 Serena Dimensions。
我特别寻找有关如何以更自动化的方式执行此审核的想法，这既准确又不耗时。
目前我的想法是在每个文件的顶部添加一条注释，其中包含该文件的版本号，一个在创建生产版本时运行的脚本，以创建一个 XML 文件或类似的文件，其中包含每个文件的文件名和版本文件文件在构建中。 然后，当我需要进行审核时，我会前往生产服务器获取包含信息的 xml 文件，并以编程方式将其与我们认为在生产中的内容进行比较，并输出报告。
有什么更好的想法。 我知道这必须已经完成，而且我还没有找到任何其他资源，这对我来说似乎很疯狂。
The organization I currently work for an organization that is moving into the whole CMMI world of documenting everything. I was assigned (along with one other individual) the title of Configuration Manager. Congratulations to me right.
Part of the duties is to perform on a regular basis (they are still defining regular basis, it will either by quarterly or monthly) a physical configuration audit. This is basically a check of source code versions deployed in production to what we believe to be the source code versions in production.
Our project is a relatively small web application with written in Java. The file types we work with are java, jsp, xml, property files, and sql packages.
The problem I have (and have expressed but seem to be going ignored) is how am I supposed to physical log on to the production server and verify file versions and even if I could it would take a ridiculous amount of time?
The file versions are not even currently in the file(i.e. in a comment or something). It was suggested that we place visible version numbers on each screen that is visible to the users also. I thought this ridiculous also, since the screens themselves represent only a small fraction of the code we maintain.
The tools we currently use are Netbeans for our IDE and Serena Dimensions as our versioning tool.
I am specifically looking for ideas on how to perform this audit in a hopefully more automated way, that will be both accurate and not time consuming.
My idea is currently to add a comment to the top of each file that contains the version number of that file, a script that runs when a production build is created to create an XML file or something similar containing the file name and version file of each file in the build. Then when I need to do an audit I go to the production server grab the the xml file with the info, and compare it programmatically to what we believe to be in production, and output a report.
Any better ideas. I know this has to have been done already, and seems crazy to me that I have not found any other resources.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以计算生产服务器上源文件的 SHA1 哈希值，并将该哈希值与源代码管理中存储的版本进行比较。 如果您可以在源代码管理中找到相同的哈希值，那么您就知道生产中的版本是什么。 如果您在源代码管理中找不到相同的哈希值，则说明生产中存在未跟踪的修改，并且您的新职位是合理的。 :)
You could compute a SHA1 hash of the source files on the production server, and compare that hash value to the versions stored in source control. If you can find the same hash in source control, then you know what version is in production. If you can't find the same hash in source control, then there are untracked modifications in production and your new job title is justified. :)
CMMI 组织陷入的典型陷阱是试图做得太过分。 如果我能提出任何建议，那就是从小事做起。 只做你需要做的事。 因此，请考虑您以前在 CM 领域可能遇到的任何问题。
CMMI 描述了组织应该做什么，但如何做则由您决定。 CMMI 规范，第 2 章非常值得一读阅读 - 它描述了规范中必需的、预期的和信息丰富的组成部分 - 基本上，目标是必需的，实践是预期的，其他一切都是信息丰富的。 这意味着 CMMI 评估员可以直接要求规范中的一小部分——目标。 在实践层面，允许采用所描述的实践或可接受的替代方案。
在配置审核的情况下，目标 SG3 是“建立并维护基线的完整性”。 SP3.2 表示“执行配置审核以维护配置基线的完整性”。 这里没有说明这些操作的频率或可能需要多长时间。
在我以前的组织中，FCA/PCA 通常仅作为产品发布过程的一部分完成，我们使用 ClearCase 作为版本控制工具，并在代码库中应用标签来定义基线。 我们没有在所有源文件中都有版本号，也没有在所有产品屏幕上都有版本号 - CM 活动正在做正确的事情并且正在做正确的事情。 得到了审计的支持，这在任何 CMMI 评估中都不是问题。
我们可以使用标签之间的增量来查看哪些文件已更改，执行差异以查看实际的代码更改。 该过程的一个重要部分是能够将这些更改链接回需求/错误报告/启动更改的任何原因。
我们的审计确实使用脚本来自动化该过程，但这些是内部开发的脚本特定于 ClearCase - 基本上它们会列出所有文件、它们在 CM 系统中的版本以及它们所属的基线/配置项。
The typical trap organizations fall into with the CMMI is trying to overdo everything. If I could suggest anything, it'd be start small & only do what you need. So consider any problems that you may have had in the CM area peviously.
The CMMI describes WHAT an organisation should do, but leaves the HOW up to you. The CMMI specification, chapter 2 is well worth a read - it describes the required, expected, and informative components of the specification - basically the goals are required, the practices are expected, and everything else is informative. This means there is only a small part of the specification which a CMMI appraiser can directly demand - the goals. At the practice level, it is permissable to have either the practices as described, or acceptable alternatives to them.
In the case of configuration audits, goal SG3 is "Integrity of baselines is established and maintained". SP3.2 says "Perform configuration audits to maintain integrity of the configuration baselines." There is nothing stated here about how often these are done, or how long they may take.
In my previous organisation, FCA/PCA was usually only done as part of the product release process, and we used ClearCase as the versioning tool, with labels applied across the codebase to define baselines. We didn't have version numbers in all the source files, nor did we have version numbers on all the products screens - the CM activity was doing the right thing & was backed up by audits, and this was never an issue in any CMMI appraisal.
We could use the deltas between labels to look at what files had changed, perform diffs to see the actual code changes. An important part of the process is being able to link those changes back to either a requirement/bug report/whatever the reason was which initiated the change.
Our auditing did use scripts to automate the process, but these were in-house developed scripts are specific to ClearCase - basically they would list all the files, their versions in the CM system, and the baseline/config item to which they belonged.
你不能使用你的源代码管理吗？ 如果您部署一个版本并使用该部署标记您的源代码控制，则可以根据源代码控制系统进行验证
can't you use your source control for this? if you deploy a version and tag your sourcecontrol with that deployment, you can then verify against the source control system