Nous avons précédemment installé le portail SonarQube sous Tomcat, ainsi que le SonarQube Runner, qui va nous permettre de réaliser aujourd’hui notre première analyse.
Dans le dossier d’installation du SonarQube Runner, nous trouvons 3 répertoires :
- Un répertoire ‘..\lib’ dédíé au .jar nécessaire à l’exécution du SonarQube-Runner.
- Un répertoire ‘..\conf’ avec le fichier ‘sonar-runner.properties’ dédié à la connexion à SonarQube et à notre base de données.
- Un répertoire ‘..\bin’ dans lequel se trouve le fichier ‘sonar-runner.bat`qui nous permet de lancer une analyse.
Avant de configurer celle-ci, arrêtons nous un instant afin de réfléchir à l’organisation de notre environnement d’analyse.
Environnement d’analyse
Lorsque vous installez un serveur d’analyse de code, il est important de bien différencier les différents espaces en fonction de leur objet :
- L’espace consacré aux différents logiciels et leurs différentes versions : Oracle, Java, Tomcat, SonarQube, etc.
- L’espace dédié à la livraison et l’installation du code source à analyser.
- L’espace dédié à l’implémentation des analyses : configuration, backups, customisations, création de rapports, extraction de données, documentation de vos analyses (utile lorsque celles-ci se multiplient ou qu’on doit revenir sur une analyse ancienne ou que notre serveur d’analyse est utilisé par différents opérateurs), etc.
SonarQube nous permet de spécifier cet espace dans le fichier ‘sonar-runner.bat’, avec la variable ‘PROJECT HOME’.
Nous allons donc rechercher dans ce fichier la ligne suivante :
set PROJECT_HOME= %CD%
et la modifier de façon à indiquer un sous-répertoire ‘\Projects’ dans lequel nous placerons les fichiers de configuration de nos analyses. Dans la réalité, je ne localiserais pas cet espace sous le répertoire du SonarQube Runner, c’est uniquement à titre de démonstration.
J’ai modifié le fichier ‘sonar-runner.bat’ pour insérer les 3 lignes suivantes :
- Afficher le répertoire ‘SONAR RUNNER HOME’ du Sonar Runner :
echo ”SONAR_RUNNER_HOME = %SONAR_RUNNER_HOME%”
- Spécifier le répertoire d’analyse ‘PROJECT HOME’ dans un dossier ‘\Projects’ que nous créons sous le répertoire précédent, et l’afficher :
set PROJECT_HOME=%SONAR_RUNNER_HOME%\Projects
echo ”PROJECT_HOME = %PROJECT_HOME%”
Configuration de notre première analyse
Afin d’effectuer une analyse, le SonarQube Runner se base sur le fichier ‘sonar-project.properties’ situé dans notre environnement d’analyse : le répertoire ‘Projects’ créé précédemment. Notre objectif est d’analyser une application Java localisée dans un répertoire ‘C:\SRC\Demo\J2EE\Source\Extranet\’.
Si vous ne disposez pas de code source, vous pouvez récupérer un example de code et sa configuration d’analyse depuis cette page : http://docs.codehaus.org/display/SONAR/Sonar+Project+Examples.
Sans entrer dans le détail des paramètres pour une analyse de code java, nous allons créer le fichier ‘sonar-project.properties’ avec les attributs suivants :
- Tout d’abord, les données obligatoires : un nom / une clé pour cette application, objet de notre première analyse, ainsi qu’un numéro de version :
# required metadata
sonar.projectKey=EXT
sonar.projectName=Extranet
sonar.projectVersion=1.0
- Et bien sûr, l’emplacement des fichiers à analyser :
sonar.sources=C:/SRC/Demo/J2EE/Source/Extranet/WEB-INF/src/
- Dernier paramètre : le langage de programmation qui décidera du parser SonarQube pour analyser cette application :
#The value of the property must be the key of the language.
sonar.language=java
Packages et classes Java
Un point à préciser si le langage Java ne vous est pas familier. Les classes Java sont organisées en packages, correspondant aux répertoires dans lesquels se trouvent les fichiers .java pour ces classes. Ce package est indiqué sur la première ligne du fichier java.
Dans cet exemple, le fichier ‘J2EEConnection.java’ se trouve dans le répertoire ‘C:\SRC\Demo\J2EE\Source\Extranet\WEB-INF\src\com\extranet\common’. Le répertoire source – encore appelé ‘root’ ou répertoire racine – à indiquer dans notre fichier de configuration d’analyse, est celui immédiatement au-dessus de tous les répertoires / packages.
Si vous avez un doute, ouvrez un fichier java de l’application à analyser et regardez la première ligne. Puis recherchez le répertoire ‘père’ du package : c’est celui que vous devez indiquer dans le fichier de configuration d’analyse du SonarQube Runner.
Normalement, il est matérialisé par un répertoire ‘src’, mais il arrive parfois que cette convention ne soit pas respectée, et que les packages soient organisés dans différents dossiers. Dans ce cas, vous devrez spécifier ceux-ci dans le fichier ‘sonar-project.properties’, en les séparant par une virgule, comme dans l’exemple suivant :
sources=../src1/,../src2/
Exécution de notre première analyse
Dans une fenêtre de commande DOS, nous lançons le fichier sonar-runner.bat.
Nous voyons bien s’afficher les 2 variables désignant le répertoire du SonarQube Runner et de notre espace ‘Projects’, ainsi que le fichier de configuration de notre analyse :
Plus loin, nous pouvons voir la mention du nom du projet indiqué dans le fichier sonar-project.properties, ainsi que le répertoire correspondant au paramètre ‘sonar.sources’.
Comme vu dans le paragraphe précédent, vérifiez que vous avez bien indiqué le répertoire racine de tous les packages.
Lorsque vous verrez dans le log d’analyse, le message ‘ANALYSIS SUCCESFULL’ :
vous pouvez consulter le portail SonarQube et voir s’afficher les résultats de votre première analyse.
Nous retrouvons le nom du projet et sa version tels qu’indiqués dans fichier de configuration d’analyse ‘sonar-project.properties’.
Nous n’avons vu ici que les paramètres les plus simples, nécessaires à l’exécution d’une analyse. Il en existe bien d’autres, que vous pouvez consulter sur cette page Analyzing with SonarQube Runner.
Nous avons donc pu mener à bien notre première analyse de la façon la plus simple qui soit, en configurant les quelques paramètres requis dans le fichier sonar-project.properties, sans nécessité de gérer des fichiers xml type Maven à la syntaxe parfois longue et complexe.
Cette manière de procéder présente cependant un inconvénient : consulter les erreurs dans une fenêtre de commande DOS n’est pas des plus convivial, surtout pour des analyses assez longues et/ou rencontrant beaucoup d’erreurs.
Heureusement, nous allons voir comment remédier à cela, grâce à notre ami Jenkins.
Prochain article : comment installer et configurer Jenkins. A bientôt.
Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.