SonarQube and Continuous Delivery Versioning

Sonar is a very good static/dynamic source code analysis tool, which I’ve used for a number of years; however, since evolving from Continuous Integration to Continuous Delivery, there are a couple of annoying limitations I’ve had to work around.

One that keeps coming back is the way Sonar can only differentiate between the last analysis or the last “version” of the project*.  This is all very well for standard CI development, where the version remains static until you’re “code complete”, but under Continuous Delivery, every commit produces a unique version or the code which, in theory, could make it all the way out to production.

Therefore, you get a problem when trying to use Sonar as a “Quality Gate”, for instance with a rule mandating “New Major Issues” or “Percentage Line Coverage” which is best exemplified by the following diagram…

Sonar Linear Quality Gate

Here you can see that when a changeset introduces a number of alerts, you can make the build “go green” again simply by fixing one or more issues.  Because the comparison is always to the last version or analysis, you can never establish a baseline.  This means it’s all too easy for the number of issues to go up, and little incentive for them to go down.

Increasing Issues

What we need is a way to mark the “last good version” and then compare against that until we get a new baseline that is equal to or lower.

Sonar Solution

Here, the number of issues can only go down, as each build that contains equal or fewer issues than the last is used as the new benchmark.  This encourages the downward trend we want.

Decreasing Issues
Putting this into practice…
So, to achieve this, we need three things:

  1. A way to record the last “good build”
  2. A way to find out the last good build
  3. A way to tell Sonar to compare against the last good build

1 & 2 are straightforward with most version control systems and Continuous Integration software.  At the end (and only at the end) of a successful pipeline, tag your source code with the version you just built.  At the beginning of each pipeline, create a job that retrieves the latest tag (on the same branch) and injects that into the rest of the pipeline as a variable you can use.

To tell Sonar how to use this value, we simply add the following parameter to Sonar Runner:

-Dsonar.timemachine.period3=${LAST_GOOD_BUILD}

This overrides the value previously known as “Since Previous Version”.  Then, when you look at a Sonar report, the “Time Changes” drop-down box should look as follows:

Sonar Time Changes

Make sure you still select “Since Previous Version” in your Quality Gate, in order to use this new feature.

* Ok, Sonar can also compare against a static date, or a period of days (e.g. last 30 days)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: