How do you configure your Quality Gates?

One of the core features of Sonar that enables developers to write Clean Code is the Quality Gate, which acts as the key indicator for whether or not your code can be merged or released.

The built-in Quality Gate (the Sonar Way) is a great starting point for users, with a focus on Reliability, Security, Maintainability, Coverage, and Duplication on New Code.

Users can also define their own Quality Gates, to meet the requirements of teams with different requirements or varying levels of maturity.

On Sonar’s own instance of SonarQube, we define six Quality Gates beyond the built-in Sonar Way:

• SonarSource Way – This Quality Profile, which serves as the foundation for the rest (and the default for projects not otherwise assigned a Quality Gate), raises the Coverage on New Code threshold to 85% and adds conditions on Overall Code to ensure there are no blocker bugs or vulnerabilities in the entire codebase
• SonarSource Way – CFamily – C/C++ Developers always have… unique needs. In this Quality Gate, the threshold for duplication in this Quality Gate has been significantly raised, and all that’s required of coverage is that some amount is reported
• SonarSource Way – Champions League – A stricter coverage condition is used (90%)
• SonarSource Way – LT Unicorn League – The team responsible for developing Sonar’s analysis engine uses this Quality Profile and has decided to hold themselves to the high standard of 95% Coverage on New Code, along with 0 Blocker or Critical Issues (to catch Blocker/Critical Code Smells, which won’t always violate the Maintainability Rating condition)
• SonarSource Way – SonarQube Team – The team responsible for developing SonarQube uses this Quality Gate, and it is identical to the LT Unicorn League… Maybe we have some consolidation to do!
• SonarSource Way – Without Coverage – We have a few projects with a significant amount of integration code, and as a result test coverage is not a strict indicator we use to release or merge, so we remove that condition while keeping the rest.

While you can define as many Quality Gates as you want, we believe that it’s important for organizations to only create a few and broadly hold teams to the same standard (so that there’s a common definition for code that meets organizational standards to be merged or released)

Now that you know how we define our Quality Gates at SonarSource, we’d like to hear from you! Tell us about…

• How many Quality Gates are you using in your organization?
• When do you decide to create a new Quality Gate?
• What conditions are you typically adding/removing/adjusting?
• Do most projects use the same Quality Gate or does every team try and define their own standards?

Or maybe the built-in Sonar Way meets all your needs and all your projects stick to it. Let us know!