One of the simplest ways to get started in improving quality and tackling technical debt seems to also be one of the hardest to convince organizations and the developers inside the organization. The idea of checking code quality upfront before checking code in would seem like a logical way to develop software. By checking the code quality before it is checked in, organizations would be able to prevent a large portion of the technical debt they are incurring, but getting them to use a tool such as SonarQube and its Quality Gates is much more difficult than most would imagine. SonarQube can be installed on relatively modest machine to get started, and then be configured along with the developers IDE so that the developer can at least do a code quality check before they check their code into the source code repository. This is the simple way to get started with SonarQube, after this it’s advisable to connect SonarQube’s Quality Gates into the Continuous Integration process. So, what are these Quality Gates?
As SonarQube has matured they have taken the concept formerly known as alerts and taken it out of Quality Profiles so that it could become Quality Gates. In order to imagine Quality Gates, you need to think of them in two distinct ways. At one level, they are a collection of the former alerts, and are instead now known as “conditions”. At a high level, they are a set of logical gates, stringing together all the conditions in the set of quality checks to determine if a project can pass.
The new changes to Quality Gates now means that the same criteria to all projects, across languages. Now you can set it up once and apply it to each project specifically, or set your favorite gate as the default.