Originally published on 2011-10-07 18:04
It's often the case that you want to have your developers perform a Coverity analysis before they check their code in to the main source branch. Here's how to set up your Streams and Projects in CIM in order to keep the developer's working code from interfering with your overall CIM results and trending.
This example assumes that you have four developers: Bob, Carol, Ted and Alice; all working on a project named "Alpha". Each developer has their own sandbox where they can check out code from the main branch, do their own development work, perform a Coverity analysis, and then check in their changed code to their Source Control system. This example also assumes that you've got a main Coverity build and analysis that you run once per day, which happens outside of the sandbox of any of the developers.
1) Set up the following Streams:
2) It may be that you have been running the centralized build and analysis for some time, so that you already have Snapshots and Triage information present in 'Alpha_Main' (or its equivalent). If this is the case, make sure you create the developer-specific Streams ("Alpha_Bob", "Alpha_Carol", "Alpha_Ted", and "Alpha_Alice") by *copying* the "Alpha_Main" Stream. This will make sure that these Streams contain copies of the existing Triage information, so that defects that have been previously found and triaged (as "Intentional" or "False Positive") are triaged the same way in the developers' private streams.
3) Set up the following Projects, each containing the following Streams:
4) Set up a policy about commits, such that:
Note that as of CIM 5.4, there is no mechanism to enforce this policy. The best way to do this is to have the commit process wrapped in a script which sends the results to the correct stream based on the username of the developer running this script.
5) With this setup, you get the following benefits:
Originally published on 2011-05-10 15:41
Unfortunately, current versions of CIM do not provide the ability to prevent users from committing to a particular Stream. We are planning on adding that functionality to a future version of CIM.
Once CIM has the ability to enforce permissions, it would naturally make sense to deny 'commit' privilege to the Alpha_Main stream to developers.
Originally published on 2011-05-10 17:01
If your question is about why make Alpha_Main stream contents visible to developers at all, the answer would be so that they can compare defects in their stream to defects in the Main stream and verify that they didn't introduce new defects and fixed the defects they intended to fix.
Originally published on 2011-07-23 08:13
I'm neither a lawyer nor a licensing expert, so don't take this next as gospel:
My understanding is that your licence applies to the LOC that you analyze, and *not* to the LOC in CIM.
For example, say you had a license for 100,000 LOC. If you were analyzing 100,000 LOC that was targeted for 2 different environments, you'd build and analyze the same code twice: once for environment A and once for environment B (e.g. Windows and Linux). This would show up as 200,000 LOC in CIM. However, since you were only analyzing 100,00 LOC in "real life", you'd be in compliance with your license.
In short: Coverity, as a company, is aware that the LOC count in CIM typically does not reflect the LOC count for licensing purposes.
Your best bet for counting LOC for compilance purposes is usually your SCM system, and not CIM. If you have further questions about Best Practices for counting LOC, please open a new thread.
Also, please be aware that the terms of individual licenses are different for different customers. As always, if you have questions about your particular situation, contact your Account Manager.
Disclaimer: I do *NOT* speak for Coverity. Contact your Account Manager if you have questions about the terms of your license. Objects in window are closer than they appear. Not a flying toy.
Originally published on 2011-10-05 13:41
We were using a scheme similar to this. Our product has multiple scrum teams working on it. We set up a Subversion Branch for each team and ran Coverity through using the branch with the idea that the branch would not be promoted if there were any new defects. Our original setup had only one "Main" project, with all the streams in that main project. This was making it difficult (not impossible, just more difficult) to determine if a defect was fixed. When we typed the CID into the Find box, it came out as "New" because it still wasn't fixed in one of the streams. Splitting the streams as outlined above into separate projects, duplicating the Main stream in each project, helped with that issue. Now typing the CID into the Find box has multiple results and shows it as Fixed in the correct Project while still being New on other Projects. In this case, the defect was a "Legacy" defect in and fixed in the Main Project. So the suggested setup is a good improvement.
Then I went to the "Branch/Personal" Project and searched for defects that were in the branch but not in Main. In this case, we know there are defects fixed in Main but still New in the Branch. The search returned nothing. I assume this was because there were no different defects. Is there some way I can search for defects that may have a different status in different streams?
My example may be a bit contrived. In this case, Main should be merged down to the Branch, and the defect in the branch would also be fixed. But what happens if we re-introduced a defect in the Branch? We want to catch this before the code is promoted to the Main line. I'm sure there are other similar issues that may cause the same problem.
Originally published on 2011-10-05 18:42
>Is there some way I can search for defects that may have a different status in different streams?
If the Streams are in the same Project, you can use the "Detected-In" filter, as I mentioned in the original article. Take a look at CIM Basics: How do I find defects that are present in one stream but not in another? for a description of how that filter works.
For example, given the "Alpha_Bob" Project described above, Including the "Alpha_Bob" Stream and Excluding the "Main" Stream should get you the defects that are only present in Bob's code stream.
Originally published on 2012-03-23 09:19
HELP? I have recently updated to Coverity 5.5.3 and they have changed this stuff and I am confused as to how this article now applies to the new revision.
Appendix A. of the cim_admin_guide is talking about creating a single <central_project>-dev-streams???
Originally published on 2012-03-23 14:19
The changes in 5.5 were two-fold.
One was that full RBAC was introduced to enforce the mechanism that William describes using in the original article.
Secondly, if you use an IDE we have a plug-in to support (Eclipse or Visual Studio) then you don't have to go through the trouble of setting all of this up manually and many of the steps would be done for you automatically.
However, if you don't use an IDE all the steps are still required, RBAC allows you to actually enforce who can see which stream (and commit to, and triage).
A stream is basically an object used to manage analysis results. Typically, users will allocate one stream per "build directory", where that build directory is used to build a particular configuration of their code. In practice, it usually makes sense to use a unique stream for each unique project, version, platform combination. For example, if you have one project (A), with versions 1 and 2, built for 32-bit Windows and 32-bit Linux, you would typically have 4 streams:
Project A, version 1, for Windows
Project A, version 1, for Linux
Project A, version 2, for Windows
Project A, version 2, for Linux
Each time you analyze one of those configurations, you commit the results to the relevant stream. That way, you'll be able to compare defects between streams--to see things like which defects exist in version 1 but not version 2, or on Windows but not Linux.
The CIM Administration and Configuration Guide (often named cim_admin_guide.pdf) describes streams and projects in more detail. Our current release, 6.0.1, has this information in Chapter 7.
Streams can be created via the web interface in the Coverity Integrity Manager (CIM), via the command line tool cov-manage-im, or via CIM's web services API.
To get a more specific answer about your problems with the Visual Studio plugin, I encourage you to submit a support ticket. They will work with you to understand exactly what you are trying to do and recommend specific steps to resolve the problem.
Before you can use development workflow, the admin for CIM needs to create appropriate projects, streams and they need to grant appropriate permissions to the users. Integrity Manager Admin Guide has this documented, just search for the section that talks about configuration for plug-ins.