I’m looking to configure a Quality Gate for our project in SonarQube to maximize code quality while avoiding excessive blockage of development.
I have a few questions:
What criteria are most commonly used in a Quality Gate for production projects? (e.g., number of critical bugs, code coverage, code smells)
Is it better to set strict thresholds (e.g., 100% test coverage) or more realistic ones for the team?
Are there best practices in SonarQube for multi-language projects or microservices?
How can we monitor the impact of Quality Gate settings on both development speed and long-term code quality?
For Java projects, is it standard practice to use the default quality profile, or is it recommended to create a custom profile tailored to the project?
I would greatly appreciate any guidance or examples of practical Quality Gate configurations.
This is a great question. You want to move toward better code, but setting the thresholds you eventually want to achieve as today’s standards means (for most people) that you can’t go to production.
This is why we’ve long advocated a focus on new code. If you look at the built-in Sonar way quality gate, you’ll see it only has conditions on new code. Here you can be both reasonable and strict.
For instance, let’s take coverage. (You’ve said 100%, but I wouldn’t require 100% coverage. Even our most ambitious teams only require 90%, and that’s only on new code, not overall.) If you look at the Sonar way quality gate, it requires 80% coverage on new code. That’s a high bar, but it’s achievable today for everyone, regardless of project state or language. Similarly, Sonar way says 0 new issues. That doesn’t mean you have to go clean up every issue in your 10-year-old, legacy project. It means that the code you merge today has to be clean. Again, doable for everyone.
We believe the Sonar way profiles are a good starting point for each language. They’re tuned to be non-controversial for most developers in most projects. (If you disagree, we’d love to hear about it!) From there, if you find yourself marking a particular rule’s issues “accepted” frequently, then it’s time to think about customizing the profile by removing the rule.