Notre série d’articles sur l’installation de SonarQube va prendre fin avec ce post. Rappelons quels en étaient les objectifs :

• Mettre en place un environnement d’analyse de code permettant de mesurer la qualité d’applications.
• Sans nécessiter de connaissances techniques en matière de Java, de bases de données, de réseau ou d’outils Open Source.

Vous êtes un pro du monde Mainframe-Cobol ou SAP, un consultant Qualité, un responsable MOA interface entre les utilisateurs et les équipes de projet, un chef de projet gérant des outsourcers pour votre département IT : cette série d’articles vous a montré pas à pas comment installer SonarQube sur votre PC (un simple portable dans mon cas) pour analyser facilement et régulièrement toute livraison de code ou version d’applications.

Et nous allons terminer aujourd’hui par une analyse du code Java que nous avons précédemment utilisé avec le SonarQube Runner, en paramétrant celle-ci de manière très simple avec le plugin SonarQube pour Jenkins.

Création d’une analyse SonarQube avec Jenkins

Notre première analyse SonarQube avec Jenkins portera sur le code Java déjà utilisé lors de notre analyse avec le SonarQube Runner.

Pour cela, nous allons créer un projet, depuis le menu de Jenkins dans la partie supérieure gauche de la page principale.

Sélectionner le menu ‘Nouveau projet’ (‘Nueva Tarea’ dans mon interface en espagnol) : Jenkins affiche la page de création d’un projet.

Il est possible de créer différents types de projets en fonction de l’outillage utilisé (comme par exemple Maven). Avec SonarQube, nous allons choisir la première option ‘Build a free-style software project’ (‘Crear un proyecto de estilo libre’ dans l’écran ci-dessous) et entrer un nom de projet :’Extranet’ dans notre exemple. Le bouton ‘Ok’ en fin de page devient actif.

A noter qu’un message d’erreur vous interdit d’utiliser un nom de projet déjà existant.

Cliquer sur le bouton ‘OK’ afin d’accéder à la page de configuration du projet.

Je ne vais pas détailler les nombreuses options disponibles dans cette page. Je ne les utilise jamais, à l’exception de la gestion des logs qui permet de les supprimer automatiquement au-delà d’une certaine date, ou lorsqu’ils deviennent trop nombreux.

Nous nous contentons de sélectionner le bouton ‘Ajouter une nouvelle tâche’ qui ouvre la liste de menus suivante dans laquelle nous choisissons ‘Invoke Standalone Sonar Analysis’.

Ceci nous ouvre la page de configuration pour ce projet :

Il me suffit d’indiquer dans cette page le fichier properties qui contient les paramètres de notre première analyse avec le SonarQube Runner, définis dans un fichier ‘sonar-project.properties’ localisé dans un répertoire ‘..\Projects (sous le dossier ‘home’ du SonarQube Runner).

Et dans ce post, je vous avais dit qu’il était important de bien gérer votre environnement en définissant clairement où se trouvent, pour chaque application, le code source et tout ce qui participe à la configuration d’analyse. J’ai ainsi, pour chaque projet, un répertoire ‘Source’ avec le code correspondant, et un dossier ‘Implémentation\Conf’ dans lequel je vais garder le fichier properties spécifique à cette analyse et de même nom.

Cette méthode a de nombreux avantages, notamment :

• Pouvoir retrouver très facilement les paramètres d’une analyse, même très longtemps après celle-ci.
• Pourvoir dupliquer très facilement les paramètres d’une analyse qui fonctionne parfaitement en copiant ce même fichier pour un nouveau projet. Il ne reste ensuite qu’à modifier les valeurs de ces paramètres, mais je sais que je n’aurais pas d’oubli dans ma configuration, et donc qu’aucune erreur ne proviendra de celle-ci.
• Si vous travaillez à plusieurs sur un serveur partagé, adopter la même configuration (et les mêmes pratiques) vous permettra de partir en vacances tranquille : tous les autres membres de votre équipe sauront exactement comment reprendre vos projets sans même y avoir participé. Cela n’interdit pas un peu de documentation (à garder dans le dossier ‘Implémentation\Docs’) mais celle-ci sera très succincte : une simple fiche de description de l’application et de votre analyse.

J’utilise donc exactement le même fichier properties que celui créé pour notre première analyse avec le SonarQube Runner.

Un autre avantage que me permet Jenkins est de pouvoir surcharger n’importe quelle valeur présente dans ce fichier depuis la page de configuration ‘Invoke Standalone Sonar Analysis’, et comme vous pouvez le voir dans la figure antérieure : spécifier un nouveau numéro de version pour cette analyse ou cette application :

sonar.projectVersion=1.1

N’oubliez pas de sauvegarder vos paramètres avant de lancer votre analyse.

Exécution et log

Une barre de progression vous montre le déroulement de celle-ci.

Un menu déroulant vous permet de voir le log pour cette tâche, durant ou la la fin de celle-ci.

En cliquant sur l’image précédente, vous pouvez voir les différents paramètres que nous avons effectivement indiqué dans notre configuration Jenkins.

Dans cette même page de log, vous disposez d’un menu qui vous permet d’afficher ce log en mode texte afin de pouvoir le sauvegarder ou l’envoyer par mail, par exemple.

Et finalement, le résultat dans SonarQube.

 

Nous avons pu voir dans cet article les principaux avantages de l’utilisation de Jenkins avec SonarQube :

• Organiser notre environnement d’analyse comme nous le souhaitons, avec un fichier de configuration spécifique à chaque projet, que nous pourrons dupliquer à volonté.
• Pouvoir surcharger un paramètre – comme le numéro de version – pour chaque analyse.
• Disposer d’un log beaucoup plus convivial à consulter qu’une fenêtre DOS.

Voliá tout ce qu’il est nécessaire de savoir afin de monter votre propre environnement d’analyse et ainsi mesurer facilement la qualilté différents de différentes applications et de différentes technologies, sans nécessiter de connaissances techniques particulières.

Je vous renvoie d’ailleurs à deux autres séries sur mon blog, portant sur l’analyse d’applications Cobol ou SAP avec SonarQube.

A vous maintenant. Et n’hésitez pas à laisser un commentaire si vos analyses sont fructueuses.

 

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.