Putting It All Together: End-to-end Quality With SonarEcosystem
The question is typically phrased like this: how do I keep developers from checking in bad code? Usually the asker has in mind some automated check that prevents commits of code containing new issues.
Typically, he's looking for a quick "turn on X" type of response, but the answer is more subtle and more powerful than that.
First, there's the "no new issues" proposition. On the face of it, it's attractive. There's no better way to keep a clean code base than to never let it get "dirty" in the first place. No new issues means nothing to clean up. But coding isn't always that straightforward. Sometimes you find yourself in a two-steps-forward-one-step-back situation. Which means that sometimes introducing new issues - temporarily - is required to get where you're going without a lot of circumlocution. And that's fine if you do it knowingly.
Of course, most of the time, you don't want to introduce new issues, and that's where the tools in the SonarEcosystem come in.
SonarLint: the first line of defense
First, there's SonarLint, which runs in your favorite IDE (assuming your favorite is IntelliJ IDEA, Eclipse, or Visual Studio) and highlights new issues as soon as you type the code.
Pay attention to what SonarLint is telling you, and you'll head most new issues off at the pass.
But even if you don't, there's still hope.
Pull request analysis
Pull request analysis is available for GitHub, Bitbucket Cloud, and Bitbucket Server.
That means that when you submit a pull request (PR) on a repository hosted on one of these services, with a little configuration you can have a "SonarTech" user comment the changed code with any new issues. Then it's up to the manual reviewer to decide if the issues are deal-breakers or acceptable in the context before merging the PR.
Unfortunately, there are issues that won't be raised in SonarLint or by pull request analysis. That's where you start managing the leak.
Last bastion: quality gates and leak management
Even if issue prevention fails - and occasionally it will - SonarQube still makes it easy to keep your application quality within acceptable limits.
First, you have the ability to set up a collection of go/no-go conditions that indicate whether or not your project is releaseable, i.e. a Quality Gate. Most Quality Gate conditions are related to changes in the Leak Period, but they don't have to be. If the project fails its Quality gate then you automatically know its quality doesn't meet your requirements.
If that's because of new issues, you'll be able to track them easily in the "Leak Period" section of the project front page, and beyond.
You can click through on any of the leak period numbers to drill down to the issues and files in question.
If checking the interface is too much bother, you can subscribe to new issue notifications, either on a project-by-project basis or globally to be automatically notified when new issues are introduced.
From there, it should be a simple matter to clean up what little leak there is.