Once you have generated the errors and warnings, there are many ways you can integrate the results with Team Foundation Server, including the following:
Create a check-in policy to ensure that all members of your team are required to catch and correct all C++ code analysis errors.
Create a check-in note to set who reviews the C++ code before it is checked-in.
Associate a warning to a work item. You can then publish it to the Project Portal, or assign it to another member of your team.
Check-in policies are essential for controlling the quality of the code entering your source code repository. Team System's source control engine comes with built-in static code analysis. All you need to do is enable it. Here are the steps:
Go to the Team Explorer pane.
Right-click on your Team Project and select Team Project Settings Source Control. The Source Control Settings dialog box will appear.
Click the Check-in Policy tab and then click New. The Add Check-in Policy dialog box appears, as shown in Figure 9-7.
Now it's time to create a check-in policy that incorporates code analysis. To do this, select the Code Analysis policy in the Create New Check-in Policy dialog box.
The Code Analysis Policy Editor will launch, enabling you to fine-tune the policy options. An obvious choice is the Enforce C/C++ Code Analysis (/analyze) option. This will enforce a static code analysis run for all C or C++ code checked into the source repository (illustrated in Figure 9-8).
You can also optionally select "Enforce check-in to only contain files that are part of the solution." This option will ensure that the checked-in code is part of a solution file.
When you are done, click OK to enable the policy.
The check-in policy types can be toggled on and off quite easily using the Source Control Settings Check- in Policy Tab. External policies can be migrated over to your current solution by right-clicking on your solution in the Solution Explorer and selecting Migrate Code Analysis Policy Settings to Solution. You will definitely need administrative access to the source control server to create or edit check-in policies. Please refer to Chapter 20 for more details.
Check-in notes are primarily used to define who you want to review the code and the information gathered during a check-in. Three predefined roles are allowed to review your code:
Security Reviewer: This is a trusted member of your team who will perform a security audit on your source code. You can test the security of an application using a variety of tools, including AppVerifier and Code Analysis for C/C++.
Code Reviewer: This is a member of your team (other than you) who is assigned the task of doing a code review. See Chapters 13 and 14 for more information on code review methodologies.
Performance Reviewer: This team member will test the performance of your code. You can learn more about performance tweaking in Chapter 12, "Profiling and Performance."
Notes can also be used for a variety of uses, including documenting any changes to the build or your code. The notes can then be compiled into product documentation at a later date. Here are the required steps to create a check-in note for your policy:
Go to the Team Explorer pane.
Select the Source Control option from the Team Project Settings.
Select the Check-in Notes tab from the Source Control Settings dialog box.
Select one of the check-in note titles: Security Reviewer, Code Reviewer, or Performance Reviewer, as shown in Figure 9-9.
Click the Add button and either select a predefined check-in note in the Name drop-down box or enter a custom role (as shown in Figure 9-10).
The notes can be enforced by selecting the Required on Check-ins option.
You can define what notes are mandatory with a great deal of granularity using the Required column. Check-in notes can be removed in a snap using the Remove button.
If you decide to check the Required Check-ins checkbox, please note that your code will not be checked in until the user (in the designated role) enters a note. This policy enforces the good practice of getting your team to document every code review before the code is reintroduced into the source repository. Until the team member in question enters a note, the source code will continue to be checked out on your local machine.
Once Code Analysis for C/C++ has generated significant errors or warnings, the next logical step is to file a bug. Use the following three steps to effectively manage the C/C++ code analysis within Visual Studio 2005 and Team System:
Understand the warning codes generated by the C/C++ code analysis engine.
Analyze recurring warnings and errors within the context of your project.
Track and resolve problems using work items.
It is in the tracking phase where work items come into play. Here are the steps to file a warning as a work item. Once it is filed, anyone on your team and the project lead will be able to effectively manage the bug:
If you can't see the Error List window, select View Error List.
Right-click on the warning of your choice.
A context menu will appear. Select Create Work Item to create a bug. For more information about work items, please refer to Chapter 19.
If you enable C/C++ Code Analysis on your project, these settings will port over to the Team Foundation Build server. Therefore, if there are any static code analysis errors, they will appear in the build server report along with other errors and warnings.