Analyse de code avec SonarQube

1. Vue d'ensemble

Dans cet article, nous allons examiner l'analyse du code source statique avec SonarQube - qui est une plate-forme open-source pour garantir la qualité du code.

Commençons par une question fondamentale: pourquoi analyser le code source en premier lieu? En termes très simples, pour assurer la qualité, la fiabilité et la maintenabilité pendant toute la durée de vie du projet; une base de code mal écrite est toujours plus coûteuse à maintenir.

Très bien, commençons maintenant en téléchargeant la dernière version LTS de SonarQube à partir de la page de téléchargement et en configurant notre serveur local comme indiqué dans ce guide de démarrage rapide.

2. Analyse du code source

Maintenant que nous sommes connectés, nous devons créer un jeton en spécifiant un nom - qui peut être notre nom d'utilisateur ou tout autre nom de choix et cliquer sur le bouton générer.

Nous utiliserons le jeton plus tard au moment d'analyser notre (nos) projet (s). Nous devons également sélectionner le langage principal (Java) et la technologie de construction du projet (Maven).

Définissons le plugin dans le pom.xml :

    org.sonarsource.scanner.maven sonar-maven-plugin 3.4.0.905    

La dernière version du plugin est disponible ici. Maintenant, nous devons exécuter cette commande à partir de la racine de notre répertoire de projet pour le scanner:

mvn sonar:sonar -Dsonar.host.url=//localhost:9000 -Dsonar.login=the-generated-token

Nous devons remplacer le jeton généré par le jeton d'en haut.

Le projet que nous avons utilisé dans cet article est disponible ici.

Nous avons spécifié l'URL hôte du serveur SonarQube et le login (jeton généré) comme paramètres du plugin Maven.

Après avoir exécuté la commande, les résultats seront disponibles sur le tableau de bord Projets - à // localhost: 9000 .

Il existe d'autres paramètres que nous pouvons transmettre au plugin Maven ou même définir depuis l'interface Web; sonar.host. url, sonar.projectKey et sonar.sources sont obligatoires tandis que d'autres sont facultatifs.

D'autres paramètres d'analyse et leurs valeurs par défaut sont ici. Notez également que chaque plugin de langage a des règles pour analyser le code source compatible.

3. Résultat de l'analyse

Maintenant que nous avons analysé notre premier projet, nous pouvons accéder à l'interface Web à l' adresse // localhost: 9000 et actualiser la page.

Là, nous verrons le résumé du rapport:

Les problèmes découverts peuvent être un bogue, une vulnérabilité, une odeur de code, une couverture ou une duplication. Chaque catégorie a un nombre correspondant de problèmes ou une valeur en pourcentage.

De plus, les problèmes peuvent avoir l'un des cinq niveaux de gravité différents: bloqueur, critique, majeur, mineur et info. Juste en face du nom du projet se trouve une icône qui affiche l'état de Quality Gate - réussi (vert) ou échoué (rouge).

Cliquer sur le nom du projet nous amènera à un tableau de bord dédié où nous pourrons explorer plus en détail les problèmes particuliers au projet.

Nous pouvons voir le code du projet, l'activité et effectuer des tâches d'administration à partir du tableau de bord du projet - chacun disponible sur un onglet séparé.

Bien qu'il existe un onglet Problèmes globaux , l' onglet Problèmes du tableau de bord du projet affiche les problèmes spécifiques au projet concerné uniquement:

L'onglet Problèmes affiche toujours la catégorie, le niveau de gravité, les balises et l'effort calculé (en termes de temps) nécessaire pour corriger un problème.

À partir de l'onglet Problèmes, il est possible d'attribuer un problème à un autre utilisateur, de le commenter et de modifier son niveau de gravité. Cliquer sur le problème lui-même affichera plus de détails sur le problème.

L'onglet Problème est livré avec des filtres sophistiqués à gauche. Ils sont utiles pour identifier les problèmes. Alors, comment savoir si la base de code est suffisamment saine pour être déployée en production? C'est à cela que sert Quality Gate.

4. Porte de qualité SonarQube

Dans cette section, nous allons examiner une fonctionnalité clé de SonarQube - Quality Gate. Ensuite, nous verrons un exemple de la façon d'en configurer un personnalisé.

4.1. Qu'est-ce qu'une porte de qualité?

Un Quality Gate est un ensemble de conditions que le projet doit remplir avant de pouvoir se qualifier pour la sortie de production. Il répond à une question: puis-je pousser mon code en production dans son état actuel ou non?

Assurer la qualité du code du «nouveau» code tout en corrigeant les codes existants est un bon moyen de maintenir une bonne base de code au fil du temps. Le Quality Gate facilite la mise en place de règles pour valider chaque nouveau code ajouté à la base de code lors d'une analyse ultérieure.

Les conditions définies dans Quality Gate affectent toujours les segments de code non modifiés. Si nous pouvons éviter de nouveaux problèmes, avec le temps, nous éliminerons tous les problèmes.

Cette approche est comparable à la correction des fuites d'eau de la source. Cela nous amène à un terme particulier - Période de fuite. C'est la période entre deux analyses / versions du projet .

Si nous réexécutons l'analyse, sur le même projet, l'onglet vue d'ensemble du tableau de bord du projet affichera les résultats pour la période de fuite:

Depuis l'interface Web, l'onglet Quality Gates est l'endroit où nous pouvons accéder à toutes les portes de qualité définies. Par défaut, SonarQube était préinstallé avec le serveur.

La configuration par défaut de SonarQube indique que le code a échoué si:

  • la couverture sur le nouveau code est inférieure à 80%
  • le pourcentage de lignes dupliquées sur le nouveau code est supérieur à 3
  • la maintenabilité, la fiabilité ou la cote de sécurité est pire que A

With this understanding, we can create a custom Quality Gate.

4.2. Adding Custom Quality Gate

First, we need to click on the Quality Gates tab and then click on the Create button which is on the left of the page. We'll need to give it a name – baeldung.

Now we can set the conditions we want:

From the Add Condition drop-down, let's choose Blocker Issues; it'll immediately show up on the list of conditions.

We'll specify is greater than as the Operator, set zero (0) for the Error column and check Over Leak Period column:

Then we'll click on the Add button to effect the changes. Let's add another condition following the same procedure as above.

We'll select issues from the Add Condition drop-downand check Over Leak Period column.

The value of the Operator column will be set to “is less than” and we'll add one (1) as the value for the Error column. This means if the number of issues in the new code added is less than 1, mark the Quality Gate as failed.

I know this doesn't make technical sense but let's use it for learning sake. Don't forget to click the Add button to save the rule.

One final step, we need to attach a project to our custom Quality Gate. We can do so by scrolling down the page to the Projects section.

There we need to click on All and then mark our project of choice. We can as well set it as the default Quality Gate from the top-right corner of the page.

We'll scan the project source code, again, as we did before with Maven command. When that's done, we'll go to the projects tab and refresh.

This time, the project will not meet the Quality Gate criteria and will fail. Why? Because in one of our rules we have specified that, it should fail if there are no new issues.

Let's go back to the Quality Gates tab and change the condition for issues to is greater than. We need to click the update button to effect this change.

A new scan of the source code will pass this time around.

5. Integrating SonarQube into a CI

Making SonarQube part of a Continuous Integration process is possible. This will automatically fail the build if the code analysis did not satisfy the Quality Gate condition.

For us to achieve this, we're going to be using SonarCloud which is the cloud-hosted version of SonaQube server. We can create an account here.

From My Account > Organizations, we can see the organization key, and it will usually be in the form xxxx-github or xxxx-bitbucket.

Also from My Account > Security, we can generate a token as we did in the local instance of the server. Take note of both the token and the organization key for later use.

In this article, we'll be using Travis CI, and we'll create an account here with an existing Github profile. It will load all our projects, and we can flip the switch on any to activate Travis CI on it.

We need to add the token we generated on SonarCloud to Travis environment variables. We can do this by clicking on the project we've activated for CI.

Then, we'll click “More Options” > “Settings” and then scroll down to “Environment Variables”:

We'll add a new entry with the name SONAR_TOKEN and use the token generated, on SonarCloud, as the value. Travis CI will encrypt and hide it from public view:

Finally, we need to add a .travis.yml file to the root of our project with the following content:

language: java sudo: false install: true addons: sonarcloud: organization: "your_organization_key" token: secure: "$SONAR_TOKEN" jdk: - oraclejdk8 script: - mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent package sonar:sonar cache: directories: - '$HOME/.m2/repository' - '$HOME/.sonar/cache'

N'oubliez pas de remplacer votre clé d'organisation par la clé d'organisation décrite ci-dessus. La validation du nouveau code et le transfert vers le dépôt Github déclenchent la construction de Travis CI et activent également le balayage du sondeur.

6. Conclusion

Dans ce didacticiel, nous avons examiné comment configurer un serveur SonarQube localement et comment utiliser Quality Gate pour définir les critères d'adéquation d'un projet à une version de production.

La documentation SonarQube contient plus d'informations sur d'autres aspects de la plate-forme.