Clean as You Code: Improving code quality with SonarQube

leboncoin tech
leboncoin tech Blog
6 min readJun 16, 2023

--

By Romain Louvet, Lead QA Engineer

I joined leboncoin in 2013 as their first Quality Engineer, a role that involved the development and maintenance of end-to-end (E2E) tests for mobile applications. The company had just released its iOS app and was working on its Android one. As the Core Quality team grew, the E2E tests became more sophisticated, comprising sanity, nightly, and full tests, followed by web tests later on, but eventually the guilds took over ownership of this part of the process. So our team, made up of 4 developers and 1 EM/PO, is now focused on developing tools and providing KPIs to assist feature teams with improving quality.

Recently, we began looking for a way to automatically block code review if the test coverage is less than 80%. The percentage represents a good balance between going for 100% test coverage, which can sometimes be unnecessary and annoying (e.g. throwing a generic exception that has previously been handled), and slipping into that overconfidence where you think test coverage will slow you down, which is precisely when you end up filing bugs. For us, manually writing comments about missing tests or tests that failed was too time-consuming. We wanted to find a tool that would help us. There are solutions available for analyzing source code in each programming language, such as ESLint for JavaScript. However, we needed a solution that could inspect code in all the languages used within the company: Java, Go, JavaScript, Kotlin, and Swift. This is how we came to try SonarQube, a platform where developers can track code quality and detect security vulnerabilities, bugs, duplications, and other code flaws.

Let’s take a look at how it has helped us improve code quality both within the Core Quality team itself and in the backend mono repository.

The Clean as You Code approach

There are three ways to ensure your code is clean using a code-analysis tool…

  • Option 1: Rewrite your projects to improve their quality.
  • Option 2: Refactor your code by fixing as many issues as possible.

However, those two options will result in an overwhelming number of bugs at once. Based on SonarQube’s first analysis of the Core Quality team’s code, we found 1,000 code smells 😱:

  • Option 3: Only fix issues in your new code and forget about legacy code.

The last option is what SonarQube’s Clean as You Code approach is built on, with each developer being responsible for the quality of their own new code. To go live, a project must pass a quality gate, which means a set of criteria must be met. SonarQube generates a report for every new piece of code after it has been tested. If it fails to pass the quality gate, the build breaks and the developers have to modify their commits accordingly.

docs.sonarqube.org/9.9

SonarSource, the company behind SonarQube, claims using the Clean as You Code approach reduces code maintenance by 40%, decreases operational, reputational, and security risks by 90%, and extends software longevity by 3 years.

But enough with the theory, let’s see how leboncoin implemented SonarQube using the Clean as You Code approach.

Implementing SonarQube within the Core Quality team

It was important for us to implement SonarQube within Core Quality team projects first so that we could give preliminary feedback to other teams.

Configuration

We run the SonarQube Community version 9.9 LTS. Our projects are written in Java 8 using the Spark framework, in Java 17 using the Spring Boot framework, and in JavaScript with React.js.

Our team uses the SonarLint plugin with IntelliJ (an open-source IDE) to visualize SonarQube errors. This plugin connects to our SonarQube instance containing our quality gate conditions; by using it we can identify issues before sending commits for review.

The sonar-project.properties file contains project configuration information:

The last property — sonar.qualitygate.wait — allows us to break the build if it doesn’t comply with the quality gate conditions.

Additionally, we added an Ansible role for accessing any project.

Quality gate definition

Our first step was to agree on the quality gate conditions — the requirements that must be met for pull requests to pass. For each metric, SonarQube provides default values.

These are the conditions we ended up with (which are very close to the default values):

The definition of each metric can be found in the SonarQube documentation.

Outcomes

Coverage

The coverage rate increased from 71% in July 2022 to 89% in March 2023.

July 2022–71% coverage
March 2023–89% coverage

Code smells

From August 2022 to May 2023, the number of code smells decreased from 381 to 355.

August 2022–381 code smells
May 2023–355 code smells

Implementing SonarQube in the backend mono repository

At leboncoin, the backend is a Go-based git mono repository where 39 domains and 695 microservices are organized into folders and subfolders.

Exploring our options

Initially we analyzed the entire mono repository with one SonarQube report. But after 45 minutes of launch on a MacBook Pro M1 with 16Go of memory, we encountered an out-of-memory error.

So we tried another option: Generating reports by domain and microservice. In order for each team to have control over their SonarQube project, they must add a sonar-project.properties file to the root of each domain and microservice. Using this method worked much better, and we are now convinced that splitting projects is the best way to quickly generate reports.

Ansible playbook example

An Ansible role creates a SonarQube report for each property file found. Here is an example of an Ansible playbook that works in parallel with SonarQube reports:

It should be noted that the free version of SonarQube we are using in our mono repository limits our options: Multiple reports cannot be generated simultaneously. As a workaround, we generate one static report every day.

What happens next

Our next step will be to move to the SonarCloud enterprise solution. This should mean we will be able to process parallel analysis reports, as well as decorate pull requests. This enterprise edition will also allow us to analyze the Swift language used to develop our iOS application. Not only that, the Clean as You Code approach will be presented to the different guilds (web, iOS, Android) to spread the word!

--

--