« Retour

Sondez votre code avec SonarQube

Quoi sert SonarQube ?

SonarQube est un outil d'analyse statique qui a pour but de mesurer la qualité du code d'un applicatif. Pour un projet donné, il fournit des métriques portant sur la qualité du code et permet d'identifier précisément les points à corriger (code mort, bugs potentiels, non-respect des standards, carence ou trop-plein de commentaires...)

L'analyse SonarQube ne remplace en aucun cas les tests unitaires, mais permet d'identifier rapidement certains défauts du codes.

Lancer une analyse SonarQube sur un projet

Prérequis

Installer SonarQube (voir la documentation officielle).

Démarrer votre instance avec la commande :

service sonar start

Configurer l'analyse SonarQube

  • A la racine du projet, créer un fichier intitulé "sonar-project.properties".
  • Compléter ce fichier avec le texte suivant :

sonar.projectKey=nom.du.projet

sonar.projectName=Nom du projet

# La version de votre projet, pas celle de SonarQube
sonar.projectVersion=1.0

# Définit l'emplacement des sources que SonarQube va analyser.
sonar.sources=.

# A décommenter si besoin
#sonar.sourceEncoding=UTF-8

  • Toujours à la racine du projet, lancer la commande "sonar-scanner".

Fonctionnalités de SonarQube

Faisons le tour des principales features de SonarQube.

Analyse des résultats SonarQube

En supposant que SonarQube soit installé en local, les résultats de l'analyse seront consultables sur http://localhost:9000/sonar/. Chaque projet dispose d'un espace d'analyse dédié.

SonarQube classe les défauts logiciels selon 3 catégories :

  • Les bugs : anomalies évidentes du code. Impactent la fiabilité (reliability) de l'application.
  • Les vulnérabilités : faiblesses du code pouvant nuire au système. Impactent la sécurité de l'application.
  • Les "code smells" : anti-patrons (ou anti-patterns). Impactent la maintenabilité de l'application. Wikipedia donne quelques exemples de code smells.

Ecran d'accueil de SonarQube

Sur l'écran d'accueil d'un projet analysé par SonarQube se trouve un récapitulatif des grandes familles de défauts :

La mention "Passed" signifie que le projet satisfait les exigences minimum définies dans l'espace "Barrières qualité". Les paramètres par défaut peuvent être adaptés.

Onglet "Défauts"

Dans cet onglet, chaque bug, vulnérabilité ou code smell est répertorié et détaillé dans une liste.

L'intérêt immédiat, orienté projet : tel un outil de bugtracking ou de gestion de tickets, cette liste permet de prioriser les points à traiter, d'évaluer leur temps de correction et de les affecter à un développeur. Le statut de chaque défaut est affiché. Les options du projets, tels que l'utilisateur affecté par défaut, peuvent être configurés (onglet "Configuration" -> "Configuration du projet").

En se positionnant en vue "Effort", on peut également voir le temps total que prendrait la correction de tous les défauts du code, ce qui peut faciliter la planification du travail d'un développeur lors d'un sprint par exemple.

Le second intérêt, orienté humain : comme chaque défaut comporte une explication détaillée et des pistes d'amélioration, le développeur est susceptible de monter en compétence et d'améliorer à long terme la qualité de son code.

Onglet "Mesures"

On y trouve des infos supplémentaires, plus générales, telles que la complexité du projet et le pourcentage de commentaires (20% étant habituellement reconnu comme un bon pourcentage). Contrairement à l'écran précédent, celui-ci n'est pas très bavard : à l'utilisateur de trancher si le taux de complexité est acceptable, par exemple. Pour en savoir plus sur les méthodes de calcul de la complexité, rendez-vous ici.

Onglet "Code"

Cet onglet est particulièrement pratique. Il permet de visualiser, fichier par fichier, les problèmes identifiés par SonarQube. Le code est intégralement affiché, avec des icônes au niveau des lignes posant problème.

Onglet "Tableau de bord"

Sur cette page sont rassemblées un grand nombre de métriques utiles pour communiquer sur la qualité du code. Les dashboards sont configurables selon un grand nombre de paramètres.

Penchons-nous maintenant sur le cœur de SonarQube, à savoir la définition des règles de qualité du code.

Gestion des règles SonarQube

Liste des règles

La liste exhaustive des règles associées aux défauts est disponible à cette adresse : http://localhost:9000/sonar/coding_rules.

Dans cet espace, il est possible de modifier la sévérité associée à chaque défaut. La détection de certains défauts peut aussi être désactivée.

Adapter les règles SonarQube existantes

Le contenu de certaines règles peut être configuré. Par exemple, la règle de nommage des variables locales en Java est vérifiée grâce à une expression régulière qui peut être changée :

Créer des règles SonarQube à partir d'un modèle (template)

Dans la liste des règles, cochez la case "Montrer uniquement les modèles". A partir des modèles disponibles, vous pourrez créer de nouvelles règles.

Cette fonctionnalité est appréciable, mais il est dommage qu'il y ait si peu de modèles disponibles.

Création de nouvelles règles SonarQube

Il est possible de créer de nouvelles règles ex nihilo, mais la démarche est un peu plus lourde. Effectivement, il est nécessaire pour cela de créer un plugin SonarQube, et donc de maîtriser l'architecture des sources. Mode opératoire ici

Lancer une analyse SonarQube depuis Jenkins

Pour intégrer pleinement SonarQube à votre démarche d'intégration continue, nous vous suggérons de déclencher des lancements automatiques de l'analyse du code depuis Jenkins.

Pour ce faire :

  1. Installez le plugin SonarQube
  2. Générez un token dans l'interface SonarQube. Pour ce faire, une fois connecté, cliquez sur votre profil, puis sur "My account" et "Generate tokens".
  3. Cliquez sur "Administrer Jenkins" puis sur "Configurer le système". Dans la partie "SonarQube servers", entrez le token précédemment généré.
  4. Créez un job et configurez-le. Créez une étape de build "Lancer une analyse avec SonarQube Scanner". Si vous ne remplissez pas les champs, ce sont les informations présentes dans le fichier sonar-project.properties qui seront prises en compte.

SonarQube et Jenkins Pipeline

Comme nous sommes de plus en plus nombreux à mettre en place ce type de jobs, voici un exemple de pipeline très simple réalisant une analyse SonarQube :

node {
    
    // Lors de cette phase de setup, nous récupérons dans le workspace de Jenkins les sources à analyser.
   stage('Setup') {
       checkout([$class: 'GitSCM', branches: [[name: '*/master']], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [[credentialsId: '***clé générée par le plugin Credentials de Jenkins***', url: 'http://votresuperdepot.git']]])
   }
   
    stage('Analyse SonarQube') {
        // Le nom du "tool" et de l'argument de "withSonarQubeEnv" correspond au nom de l'instance SonarQube telle que défini dans Jenkins, dans "Configurer le système" > "SonarQube servers" > "Installations de SonarQube" > "Nom"       
        def scannerHome = tool 'Sonar';
        withSonarQubeEnv('Sonar') {
            sh "${scannerHome}/bin/sonar-scanner"
        }
   }

}

Ce qu'il ne faut pas attendre de SonarQube

Une exactitude indiscutable

Chaque défaut identifié par SonarQube doit être qualifié ; nul logiciel de test automatisé n'est à l'abri d'un faux positif.

Un substitut aux revues de code

Les analyses quantitatives fournies par SonarQube peuvent être trompeuses : ce n'est pas parce que 20% des lignes d'une application sont des commentaires que ceux-ci apportent de la valeur ajoutée. De même, ce n'est pas parce que SonarQube n'a pas identifié de duplicats que le programme ne comporte pas de redondances.

Même si SonarQube est très utile pour identifier des défauts spécifiques et donner une vision d'ensemble de la qualité du code, ses analyses gagnent à être complétées par une revue de code réalisée par un humain.

Conclusion

SonarQube permet d'identifier très rapidement les anomalies de code d'une application. Mais c'est une solution qui doit aller de pair avec une stratégie globale de qualité de code. Il faut connaître son applicatif afin de pouvoir analyser les reportings, trancher sur ce qu'il faut ou non corriger et fixer des seuils en-deçà desquels la qualité sera jugée insuffisante.

Vous aimerez peut-être...

La qualité de code en direct avec SonarLint !

SonarQube met son grain de sel dans Gitlab !

Un avis ? Un commentaire ?

Cet espace est pour vous.