Qualité de code avec Sonar

J’ai entendu parlé de Sonar pour la première fois en 2008. Je travaillais alors comme consultant pour un éditeur de logiciel spécialisé dans le domaine de la qualité logicielle et de l’Application Intelligence. A l’époque, Sonar commençait tout juste à être connu mais n’était perçu encore que comme un agrégateur de résultats d’analyse fournis par différents outils.Courant 2008, je réalise une étude comparative pour le client pour qui je travaille, et là, je me rends réellement compte qu’il s’agit d’une solution crédible pour l’audit de code et pour l’inspection continue. La grande différence avec les outils avec lesquels je travaille chaque jour et la réelle automatisation et l’extensibilité.

Comment que ça marche?

Le principe de fonctionnement de Sonar est simple. Les concepteurs ont eu la bonne intuition de s’appuyer maven qui est aujourd’hui un outil largement répandu dans le monde de l’intégration continue Java. En une simple ligne de commande, on réalise les contrôles qualités de son application et on dispose de tableaux de bords qui fournissent des indicateurs quantitatifs et qualitatifs sur le code source analysé.

C’est là qu’entre jeu le deuxième pilier de l’architecture de sonar: Le serveur Sonar qui héberge les différents widget sonar, les profils qualité, la base de données des règles, des mesures et des violations, les plugins additionnels et enfin l’API Sonar qui permet d’enrichir le produit avec des nouvelles fonctionnalités.

Fonctionnement de Sonar

Comme le montre le schéma (issue d’une présentation de Sonar), Sonar est au départ prévu pour effectuer de l’analyse de code Java. Il s’appuie sur des outils bien connus du monde Java: PMD, Checkstyle, Findbugs, Surefire, Cobertura, etc… Le projet connait de nombreuses évolutions notamment au niveau des plugins de présentation des différentes violations présentes au sein de l’application analysée: Timeline, Technical Debt, Squid ou Views.

L’API Sonar et le support d’autres langages

L’API Sonar permet d’étendre les fonctionnalités du produit de deux manières différentes. Sous la forme d’extensions batch side et server side.

  • Les extensions batch side sont celles qui s’executent au sein du plugin maven de sonar. C’est le cas par exemple des plugins qui d’analyse d’autres langages
  • Les extensions server side s’executent côté server Sonar. C’est le cas des extensions web services, ou des widget additionnels

L’équipe Sonar a mis à disposition une forge logicielle hébergée sur codehaus pour les développeurs qui désirent s’impliquer dans le développement de plugin. Le point d’entrée est la page suivante: http://docs.codehaus.org/display/SONAR/Coding+a+plugin

Depuis la version 1.5, le support d’autres langages est possible. Mais ce n’est qu’avec la version 2.0 qu’arrivent réellement des plugins pour le support d’autres langages de programmation: Flex (ActionScript), C, Cobol, PL/SQL, VisualBasic, .Net et PHP. L’API Sonar Plugins évolue au cours de l’année 2010 en version 2.2 et casse la compatibilité avec les versions précédentes mais introduit de nouvelles possibilités.

Le développement de plugin pour la plateforme est grandement simplifié par l’utilisation d’archetype et l’utilisation de maven pour lancer un serveur sonar automatiquement téléchargé et initialisé.

Installer maven

Maven est un outils permettant de compiler, construire, packager et livrer des projets en faisant de l’intégration continue. Il s’appuie sur les notions de

  • repository (dépôt) de binaires qui est un répertoire sur la machine locale sur laquelle les binaires (jar, war, zip, etc..) sont téléchargés et copiés pour une utilisation pour la compilation d’application en local
  • repository distant qui est un dépôt de binaire central accessible à travers le réseau
  • goal qui est un tâche rattachée à une phase et à un plugin qui permet de réaliser des actions nécessaires à la construction d’un binaire (exemple compile, process-resources, etc…)
  • plugin qui permet d’étendre les fonctionnalités de maven pour la réalisation d’autres actions ou d’opérations nécessaires ou connexes au build (exemple: générer la documentation, calculer le taux de couverture de test, générer des rapports, etc…)

Avant de commencer, assurez vous que java est installé sur votre système et que la variabe JAVA_HOME est définie.
L’installation de maven commence par son téléchargement depuis le site maven.apache.org. Il faut ensuite simplement extraire les binaires dans un répertoire et faire pointer la variable d’environnement MAVEN_HOME vers ce répertoire. Et ajouter $MAVEN_HOME/bin à votre PATH.

Le répository maven local sera crée par défaut dans le répertoire $HOME/.m2/repository.

Installer Sonar

L’installation de sonar consiste à:

  • télécharger la distribution de Sonar
  • décompresser l’archive dans un répertoire $SONAR_HOME
  • lancer le serveur depuis $SONAR_HOME/bin/ en choisissant le répertoire correspondant à la plateforme sur laquelle sonar est installé

Pour de plus amples détails ou des configurations particulières (utilisation d’un serveur d’application ou d’une base de données externe), il faut se reporter à la documentation de Sonar.

Analyser un projet

Une fois le serveur installé et lancé, l’analyse d’un projet se limite à lancer la commande suivante dans le répertoire du projet.

[code]mvn sonar:sonar[/code]

Si votre projet est un projet Java utilisant déjà maven, vous n’avez rien à faire. Dans le cas contraire, il y’a plusieurs possibilités.
  • Pour un projet Java (ou Flex), le plus interressant est de “maveniser” votre projet afin d’automatiser son build, la gestion des dépendances, le reporting et surtout l’inspection continue avec Sonar.
  • Si vous utilisez un autre outil de build (ant par exemple), il est possible de réaliser une configuration “light” permettant de réaliser rapidement une première analyse. Pour cela, il suffit de créer un fichier pom.xml à la racine de votre projet avec le contenu ci-dessous. Je ne recommande pas ce mode de fonctionnement, car il y’a de réels avantage à utiliser maven et car ça vous éloigne du mode de fonctionnement standard.[code language=”xml”]<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>[GROUPID]</groupId>
    <artifactId>[ARTIFACTID]</artifactId>
    <name>[PROJECT NAME]</name>
    <version>[PROJECT VERSION]
    </version>
    <build>
    <sourceDirectory>[SOURCE DIRECTORY]</sourceDirectory>

    <plugins>
    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
    <source>1.5</source>
    <target>1.5</target>
    </configuration>
    </plugin>
    </plugins>
    </build>
    <properties>
    <sonar.light>true</sonar.light>
    </properties>
    </project>[/code]

  • Pour un projet PHP, le pom.xml peut-être encore plus réduit, du fait que maven n’est pas nécessairement utilisé pour effectuer la compilation du projet. Il existe par ailleurs un projet php-maven (www.php-maven.org) qui donne la possibilité de le faire. Si vous utilisez PHP, je suis interressé par vos retours sur ce projet.
    [code language=”xml”]<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>de.phpunit</groupId>
    <artifactId>phpunit</artifactId>
    <name>PHPUnit</name>
    <version>1.0</version>
    <!– For the moment, specify pom as packaging for php projects –>
    <packaging>pom</packaging>
    <build>
    <!– You cannot omit this one, because maven will implicitely add src/main/java
    to it –>
    <sourceDirectory>${basedir}</sourceDirectory>
    <testSourceDirectory>${basedir}/Tests</testSourceDirectory>
    </build>
    <properties>
    <sonar.language>php</sonar.language>
    </properties>
    </project>
    [/code]

La dernière étape consiste à se rendre à l’adresse http://localhost:9000/ et à visualiser le tableau de bord récapitulant les mesures et violations du projet.

Après ces quelques étapes, vous disposez d’une plateforme d’inspection en continue qui vous permet de suivre l’évolution de nombreux indicateurs concernant le code source de vos projets. Dans les articles suivants nous verrons comment exploiter ces métriques au profit de votre projet ainsi que les explications et l’utilisation d’éléments de qualimétrie courants.

Leave a Reply

Your email address will not be published. Required fields are marked *