Static Analysis for .NET Builds

Back to the fifth installment of JenkinsHeaven....

So you have successfully compiled and tested your application. The little ball is blue (or green) and the console log says "BUILD SUCCESSFUL" That's good, but it is far from the end of the story.

This week I intend to talk about the next part of the build process - Reporting. More specifically: static analysis.

The dashboard nature of Jenkins and its ability to bring all your reports together is one of its many strengths, the job's "homepage" can be enriched with lots of useful metrics with the addition of post build steps to the build process. These post build steps should be placed after all your testing steps (if part of the same build) or in a downstream build.

The key purpose of static code analysis is to improve the quality of your code base (improving the maintainability and manageability aspects). The ideas of technical debt and DRY are key here.

Static analysis highlights where your code base needs further work - especially refactoring (DRY). These results can highlight to the project manager where

the quick wins are and be an input into the development of a roadmap for future releases - both bug and feature.

Reporting and the graphing capabilities of Jenkins makes exposing and communicating these metrics to the wider stakeholder community easy.

There are a myriad of static analysis tools available, so I will not attempt to cover them all.

Here are the ones I currently use:

Open Tasks Trend

This scans the files matching the mask you specify (e.g. **/*.cs) for incidents of "task tags" By default when you check the "Scan workspace for open tasks"

checkbox High priority is set to FIXME, Normal priority is set to TODO, Low priority is set to TBD.

The result is a task histogram on the project page.

FXCop

You will need to have FXCop installed on your build machine.

Microsoft documentation on the FXCop tool here.

Version 10.0 download.

Version 1.36 download.

Windows 7 SDK download

Configuring FXCop for Jenkins is a two step process:

1. Add a Windows Batch command post build step to execute FXCop passing in the workspace relative path the application dll and outputting a .xml result file.

2. Configure the Violations plugin to produce a report using the xml file output from FXCop as the input. Here you can also set the number of violations that you want to represent "sunny", "thundercloud" and "unstable" (yellow ball).

CCM

You will need to have the command line version of CCM installed on your build machine. You will need to tell Jenkins where it is installed in the Manage Jenkins page.

Also, install the CCM plugin from the updates center. This is not part of the violations stable of tools.

1. Add an Invoke CCM post build step to execute CCM passing in the list of workspace relative paths of folders that contain your source. (separated with spaces works for me).

The result is a CCM graph on the project page.

There appears to be a bug with CCM (that or there is something I don't understand): When you tell Jenkins where your CCM installed you also specify a number of how hard you want it to look at your code. If you increase this number (and don't change your code) you'll get a higher complexity result. Doesn't seem right. Give it a try yourself. Am I wrong? Is there something I'm missing?

Simian

I love this plugin. Simian assists you with the DRY principle by highlighting similar pieces of code which should encourage you to refactor. I was banging my head with this plugin for a while until the developer kindly released version 2.3.31 on 3rd February. (My friend Bruno suggested that the release be called the "Gray" release after I reported my issue. I see that version 2.3.32 was released at the end of April.)

Being part of the Violations stable of plugins, configuring simian to run as part of your build is the very similar to FXCop

1. Add a Windows Batch command post build step to execute Simian passing a file mask and outputting a .xml result file. I also tell Simian to exclude all designer.cs, Reference.cs and Test.cs files. like so:

simian-2.3.35 **/*.cs -formatter=xml:simian-output.xml -failOnDuplication- -reportDuplicateText+ -excludes="*/*.designer.cs" -excludes="*/*Reference.cs" -excludes="*/*Tests.cs"

2. Configure the Violations plugin to produce a report using the xml file output from simian as the input. Here you can also set the number of violations that you want to represent "sunny", "thundercloud" and "unstable" (yellow ball).

All these static analysis graphs appear above my test results graph in the RHS pane on the job home page.

Hopefully you found this post useful. What else would you like to hear about?

I would be interested to hear what metrics others are collecting to help improve the quality of their code base.

Come visit my other site at fullcirclesolutions.com.au. All my best ideas are distilled into commercial tools and made available for purchase.

Till next time....