Technical debt and managing "leak"
The first version Sonar came out in November 2007.
Sometime in the last few years the name changed to Sonarqube.
Which means it's pretty old.
Some teams have been early adopters of the tool and a process around making use of it.
I had a delivery manager who told me all about almost as soon as it came out.
Other organisations have been slower to start looking at managing technical debt, but are getting there.
The easiest way to manage technical debt is address it as you create it.
Tools like SonarLint
Allow developers to do on the fly quality analysis. It's not as good running a full analysis, you don't get test coverage or duplication checking, but you get code quality issues for the file you are working on.
It's much harder to resolve any issues a few days, a week or months later.
Some projects are "new" or "greenfield", and have started with this process from the onset.
Which means that they have a lot more options on how they manage there code and they can more easily adopt contemporary processes (for example DevOPS, CI/Cd, TDD).
To manage quality, SonarQube allows the use of quality gates.
A gate can be used to flag when a new issue is introduced. So that if you can manage the code quality from the start of a project,
It a lot easier to monitor a code base with zero issues than a code base with many.
A simple quality gate can be set so that you will be notified on any issues. Either by using a "build breaker" or by monitoring the build.
For projects that are older and that have a larger amount of technical debt, another strategy using quality gates is needed.
The Sonar team came up with a concept called "leak"
The premise of managing "leak" is to ensure that no new issues are added (hopefully older issues get remediated in the process).
So a developer who changes an old piece of code isn't prevented from delivering value based on an absence on test cases or existing issues. But she cannot make the code worse. So if there was very little test coverage before, then they at least have provide good test coverage for their new code.
There aren't too many demo's out there on how to setup and manage projects running using the leak period, so we have been looking at how it's done for one of our customers.
We will be looking to do a demonstration and I have attached the links below.
Otherwise I have documented the steps we followed below.
Configure the rules that you are interested in.
Setup the quality gate with an appropriate leak period.
0 new issues, or 0 new Major issues, or 0 new critical issues, there a few options. In this example we have 0 new Issues, no matter the severity.
In the example we have done, we going to assume that our code base that has our current technical debt is going to analysed as a version called "Baseline".
This might be the point at which you take a branch, the branch where you will making new code that you are looking to add new functionality but without introducing more technical debt.
In the administration console, under "differential views", you can set the leak period to be a version name. In this case I used "Baseline".
We updated the Sonar properties file to create the Baseline, by setting the version as :
sonar.projectVersion=Baseline
Then run an analysis.
This creates the "Baseline" that you will be measuring new issues against.
Now, you create a new Feature version that will track your new changes.
Update the Sonar properties file to create the feature version.
sonar.projectVersion=Feature1
If we run the analysis now, the quality gate will not be triggered, as we have no new issues. The code hasn't changed.
Going forward, if any new code has any issues, then the analysis will trigger the gate to fail.
Adding some new code.
That has a new issue and running an analysis causes the quality gate to fail.
At this point the developer (or team) would jump into SonarQube, see what the issue is and look to remediate it there and then, rather then waiting to review the code at the end of the feature. Reviews at the end are usually around the same time that the testing has finished and the business has signed off.
Those reviews often end up being a waste of time and tick-and-flick, where no one is willing to make the changes and re-test the code. So the issues roll over to the next release, when the team is already focused on the next feature, not the past issues. So the issue ends up getting fixed in next months release if Never-ember (it's not on your calendar).
We are going to do some demonstrations over the next few weeks for those that might be interested in seeing this in action.
Thursday the 6th of June, 9:00pm Sydney time.
Tuesday the 11th of June, 8:30pm Sydney time.
Wednesday the 12th of June, 11:30pm Sydney time.
If you are interested in finding out more about "leak", our product or were interested in a demonstration, please drop me an email to:
Or contact me via the contact page on our website.
Regards
Richard