Enabling code analysis check-in policy

Many organizations recommend certain checks be done before committing code into source control. The cost of fixing bad code increases overtime. There is incentive in identifying and fixing issues in code early. We discussed the definition of done in the previous chapter; think of this as the definition of check-in. In TFS, a check-in policy is a rule that is executed during the check-in operation to ensure that the selected change set is okay to commit. The check-in policies are stored on the server and executed on the client machines at the time of check-in. Check-in policies are only supported in TFVC projects. While TFS has some preconfigured check-in policies, several other check-in policies are added by TFS Power Tools. In this recipe, you'll learn how to configure the code analysis check-in policy. The code analysis check-in policy requires that code analysis is run before check-in.

Getting ready

To complete this recipe, you'll need:

• A TFVC Team Project called FabrikamTFVC. Refer to the Creating a Team Project using the Scrum Template recipe in Chapter 1, Team Project Setup, for instructions on how to create a TFVC Team Project.
• In order to configure check-in policies, you need to have the edit project-level information permission set to Allow for your account. Add yourself. If you are part of the Project Administrators or Project Collection Administrators group, you'll already have this permission.

  Note

  Check-in policies that are defined using Team Explorer everywhere only apply when you check in using the Team Foundation Server plugin for Eclipse or the cross-platform command-line client for Team Foundation Server. If another client such as Team Portal or Team Explorer in Visual Studio is used, these policies do not apply. Similarly, policies that are defined using Team Portal or Team Explorer in Visual Studio are not applied when you check in using the Team Foundation Server plugin for Eclipse or the cross-platform command-line client for Team Foundation Server.

How to do it...

1. In Visual Studio, open Team Explorer and click on Settings. Once navigated into the Settings view, click on the Source Control hyperlink. From the Source Control Settings window, select the Check-in Policy Tab. Click on the Add button and select Code Analysis, then click on OK.
   
2. In the Code Analysis Policy Editor window, from the rule set dropdown, select Microsoft Managed Recommended Rules and click on OK:
   
3. Check Enforce check-in to only contain files that are part of current solution. This option allows you to stop the check-in of any file that is not part of the current solution. This is a good option to enable as developers can accidently check in files into the source control without linking the file to the solution. This can possibly result in build issues.
   

   Note

   The code analysis ruleset definitions are stored in the C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets folder.

4. From the FarbikamTFVC project, open FabrikamFiber.CallCenter.sln:
   
5. In FabrikamFiber.Web from Controllers, open HomeController.cs:
   
6. Copy the following code in the Index() function of HomeController.cs:

   try
   {}
   catch(Exception ex)
   {}
   

7. From Team Explorer, navigate to the pending changes window and check in the code changes into TFS. A policy warning is issued since the static code analysis hasn't been run:
   
8. Double-click on the warning message to see the details:
   
9. Trigger code analysis by selecting Run Code Analysis on Solution from the Analyze menu in Visual Studio:
   
10. Code analysis finds the issue with the newly added code. The developer would have missed this if the code analysis wasn't run. The code analysis policy ensures that code analysis is run before the code can be checked in:
    
11. Since code analysis has now been run, checking in the code will not issue a check-in policy violation warning message.
    

How it works...

Check-in policies are used to enforce mandatory software development practices. Policy is enforced during the check-in process. Since TFVC check-ins are processed on the server, the check-in request is intercepted to force an execution of the check-in policy on the client side. If a user attempts to perform a check-in, in violation of a policy, the check-in is blocked.

There are four Team Project check-in policies that can be specified (in order to use check-in policies, you need to be connected to Team Foundation Server):

• Builds: This requires that any build breaking issues that were created during a build must be fixed before a new check-in.
• Code analysis: This requires that the code analysis is run before check-in.
• Testing policy: This requires that check-in tests are completed before check-in.
• Work Items: This requires that one or more Work Items be associated with the check-in.

The check-in policy can be overridden by clicking on the Override Warnings hyperlink; you can continue to check in the code after providing a reason for the override:

Note

You can turn off the policy override option in Team Explorer using a no policy override server side plugin. Read the following blog post for more details http://bit.ly/1jUhZ9y.

There's more...

So far, we have talked about check-in policies for TFVC projects. Using the TFS API, it is possible to create a custom check-in policy for Git projects. The server-side plugin listens for the PushNotification that is raised at the time of Git push event. Refer to for Git repositories to validate that a commit message has been associated with the push.