Quality Gate Ranges

As defined in SonarQube, Quality Gates are collections of simple boolean thresholds set on project measures. A project must pass each of the thresholds in order to pass the Quality Gate as a whole.

The default Quality Gate will be applied to all projects but it is possible to define custom Quality Gates by use case or by application business. The following list describe the metrics that define a Quality Gate:

Blocker issues

The maximum blocker issues is 0. It is very important to ensure that all blocker issues has been fixed due to the fact that this type of issues are bug with a high probability to impact the behavior of the application in production: memory leak, open JDBC connections... The code MUST be immediately fixed.

Duplicated lines (%)

This metric shows the number of physical lines touched by duplication. It is very important reduce this metric to the minimum and keep away the spaghetti code. This spaghetti code usually leads to a number of duplicated lines higher than 25%.

New critical issues since last version

This term makes reference to the generation of new issues of status Critical since the last version. What New critical issues really measures is how good is the code compared to the last time that the sonar analysis was run.

Public documented API (%)

A low percentage of commented public methods entails that the development team has ignored the documentation guide. It is very important to make this value higher than the 50% to make sure that the code is maintained when the development team changes.

Technical debt

The Technical debt is the number of man-days needed to fix all problems in the code base. It can be seen as the amount of effort that a team must invest in order to carry the application to a determined quality policy.

Technical Debt Ratio (%)

A product with a technical debt ratio of 5% is clearly in better quality shape than a product with a ratio of 25%. But when is the right time to start worrying about the code quality?

There are different types of projects and every programming language has its own characteristics. A safe rule of thumb is that codebases with a technical debt ratio over 10% should be considered candidates of poor quality. In such cases, the management team should work with the development team to decide how they want to start eliminating the debt.

Test coverage (%)

If the test coverage ratio is lower than the 50% this means that the application has too much functionality that is not being tested on each release. This kind of applications use to have a lot of regression issues.