SonarQube est un outil de reporting sur la qualité des projets informatique. Bien qu’à l’origine fait pour le Java, la communauté Open Source a permis l’intégration de Sonar avec d’autre langages : cobol, flex, php, c++ et .NET. Sonar centralise les rapports d’outils d’analyse de code pour afficher des informations comme la couverture de test, le respect des normes de développements, la complexité, la duplication… Sonar est conçu pour s’intégrer dans une usine de développement logicielle (Hudson/Jenkins ou bien justement Team Foundation Server (TFS)). Cette intégration permet une mise à jour des métriques à chaque build !

SonarQube est une plateforme qui permet le suivi des tendances.

En plus d'éviter la régression, comme le dit la définition de Wikipédia l'intégration continue est bonne pour la réduction des risques :

  • Découplage de l'environnement de développement

Si cela marche sur jenkins OK sinon pas OK. Si cela marche chez le développeur et pas sur jenkins, il n'a pas commiter tout.

  • Découverte des défauts au plus tôt. Le coût d'un bug en informatique est petit en phase de développement. Mais il y en a beaucoup. Peu de bugs mais très cher après.
  • Qualité accrue aux métriques périodiques
  • Information sur la santé du projet. Si le projet a beaucoup de tests en erreurs

L'intégration continue crée le concept de "non évènement". Tout ce qui était pénible et riche en erreur par un humain est fait automatiquement. Le build est out les 12 heures automatiquement par exemple.

  • Intégration des différents modules,
  • Tests de l'application
  • Inspection du code. Des métriques automatiques.

Au bout d'une demi-heure, si tout est vert, le déploiement se lance...

  • Déploiement de l'application sur les environnements
  • Livraison de l'application

L'intégration continue :

  • Automatiser les builds et les tests
  • Commit fréquents
  • Garder le build de l'application rapide
  • Coresponsabilité des déploiements.

Les sujets abordés dans ce billet sont :

Les premiers points sont grandement inspirés du blog de Jean-Pierre FAYOLLE. Le dernier point est inspiré du blog de Maxime ARNSTAMM. L'environnement d'installation étant plus compliqué (2 serveurs virtualisé dont un serveur Remote Desktop Services (RDS)) par rapport à une seule machine portable, il apparait que de simples commentaires à la marge n'auraient pas été suffisamment démonstratif que la totalité de la démarche même si elle est reprise d'un autre blog. DE plus, le serveur Sonar utilise MySQL plutôt qu'Oracle.

Installation du portail web SonarQube

Prérequis : Création de l'utilisateur MySQL sonar sur le serveur UBSBASE3

Au niveau d'une fenêtre SQL de PHPMyAdmin, exécutez les ordres MySQL suivants:

CREATE DATABASE sonar CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE USER 'sonar' IDENTIFIED BY 's0n@r';
GRANT ALL ON sonar.* TO 'sonar'@'%' IDENTIFIED BY 's0n@r';
GRANT ALL ON sonar.* TO 'sonar'@'localhost' IDENTIFIED BY 's0n@r';
GRANT ALL ON sonar.* TO 'sonar'@'ubsrds3.ubs-bi.local' IDENTIFIED BY 's0n@r';
GRANT ALL ON sonar.* TO 'sonar'@'ubsrds2.ubs-bi.local' IDENTIFIED BY 's0n@r';
FLUSH PRIVILEGES;

Les dernières commandes permettent d'exécuter des analyses avec le @@Sonar

 Runner@@ depuis deux serveurs RDS.

Création d'une application war pour un serveur Apache Tomcat déjà existant

La première étape de cette installation va consister à télécharger la dernière version de Sonar depuis la page de download http://www.sonarsource.org/downloads/. Dans notre cas, à la date à laquelle je rédige ce billet, ce sera la version 3.7.4 (version LTS pour Long-Term Supported). Évidemment, vous pouvez installer une éventuelle version plus récente mais il n'est plus possible de créer à partir de la version 4.0 une application war pour un serveur Apache Tomcat déjà existant. Il faut avoir un serveur dédié qui se trouve être un serveur Tomcat.

Donc, pour une nouvelle installation, nous allons télécharger le fichier sonar-3.7.4.zip et le décompresser dans un répertoire \UBS\outils\sonar-3.7.4.

Dans ce répertoire, nous cherchons dans le dossier .\conf le fichier sonar.properties afin de l’éditer. Dans ce fichier, un utilisateur sonar est déjà défini avec son password :

sonar.jdbc.username: sonar
sonar.jdbc.password: sonar

Il faut changer le mot de passe en sonar.jdbc.password: s0n@r Cela correspond à l'utilisateur MySQL que nous avons créé dans la section précédente.

Nous ne voulons pas utiliser la base de données livrée par défaut avec Sonar, donc nous mettons les lignes suivantes en commentaires :

# Comment the following line to deactivate the default embedded database.
# sonar.jdbc.url: jdbc:h2:tcp://localhost:9092/sonar

Et nous recherchons la section dédiée à la configuration de MySQL afin de paramétrer notre connexion :

sonar.jdbc.url: jdbc:mysql://ubsbase3:3306/sonar?useUnicode=true&characterEncoding=utf8&rewriteBatchedStatements=true

Ma base de données MySQL s'appelle sonar est installée sur serveur écoutant le port 3306 (port par défaut pour MySQL), sur ma propre machine ubsbase3.ubs-bi.local. Ce sont les seuls paramètres à spécifier en fonction de votre propre environnement.

Le driver JDBC de MySQL mysql-connector-java-5.1.24.jar est déjà présent dans le répertoire \extensions\jdbc-driver\mysql de Sonar.

Dernière étape : générer le fichier sonar.war que nous utiliserons pour déployer Sonar sous Tomcat. Tout le monde sait ce qu’est un fichier .war : un fichier compressé qui va nous permettre d’installer l’application Web – le dashboard ou tableau de bord – de Sonar.

Auparavant, vous pouvez souhaiter télécharger (depuis la page Plugin Library) les plugins Sonar que vous souhaitez utiliser. Copiez les dans le répertoire de Sonar \extensions\plugins. Ce n’est pas absolument indispensable, vous pouvez le faire ensuite. J'ai installé les plugins open-source et gratuits suivants qui me permettent de gérer les langages Android, C#, flex, Groovy, javascript, PHP, python, web et XML :

  • sonar-android-plugin-0.1.jar
  • sonar-csharp-plugin-2.1.jar
  • sonar-csharp-stylecop-plugin-2.1.jar
  • sonar-dotnet-fxcop-plugin-2.1.jar
  • sonar-dotnet-gallio-plugin-2.1.jar
  • sonar-dotnet-gendarme-plugin-2.1.jar
  • sonar-dotnet-ndeps-plugin-2.1.jar
  • sonar-dotnet-plugin-2.1.jar
  • sonar-flex-plugin-2.0.1.jar
  • sonar-groovy-plugin-1.0.1.jar
  • sonar-javascript-plugin-1.6.jar
  • sonar-php-plugin-2.1.jar
  • sonar-python-plugin-1.1.jar
  • sonar-web-plugin-2.1.jar
  • sonar-xml-plugin-1.0.1.jar

Afin de construire le fichier sonar.war, il suffit de lancer le fichier build-war.bat depuis le répertoire \war. Celui-ci sera généré dans ce même répertoire.

Nous pouvons maintenant le déployer. Je me contente de le copier dans le répertoire \UBS\serveurs\UBS-OS-GISBI-Server\tomcat\webapps de mon serveur courant Tomcat, puis de démarrer ce serveur Tomcat afin de créer un nouveau répertoire – une nouvelle webapp – \sonar avec le contenu du fichier .war.

La première fois que vous allez installer Sonar, celui-ci va prendre quelques minutes afin de créer son schéma de base de données dans la base de données MySQL définie auparavant. Laissez-lui le temps d’accomplir cette tâche avant de lancer la webapp Sonar.

Celle-ci est maintenant accessible depuis votre navigateur, à l’URL correspondante au répertoire de la webapp Sonar : http://ubsbase3:9090/sonar/ dans mon environnement.

Et c’en est fini de la configuration de Sonar. Tout changement de configuration ou toute mise à jour nécessite de regénérer l'application sonar.war et de la redéployer sur le serveur Tomcat.

Si vous souhaitez prendre un peu d’avance et essayer par vous-mêmes, ou si vous voulez récupérer du code exemple à tester, SonarSource fournit différents exemples depuis cette page.

Installation du SonarQube Runner sur le serveur UBSRDS3

Nous avons précédemment installé le portail SonarQube sous Tomcat, Il nous faut le SonarQube Runner, qui va nous permettre de réaliser aujourd’hui notre première analyse.

Nous allons d’abord télécharger le fichier d’installation du SonarQube Runner depuis la page Installing and Configuring SonarQube Runner. Dans mon cas, à la date de ce billet, il s’agira de la version 2.4 LTS.

Nous décompressons le fichier sonar-runner-dist-2.4.zip dans un répertoire \UBS\outils\sonar-runner-2.4.

Dans ce répertoire, nous recherchons le dossier \conf afin de modifier le fichier sonar-runner.properties.

Nous allons utiliser ce fichier properties afin de gérer la connexion avec le serveur SonarQube, en fait notre application SonarQube sous Tomcat. Il suffit en fait d’indiquer les mêmes paramètres que lors de l’installation du portail SonarQube.

Donc, nous indiquons son URL :

#—– Default Sonar server
sonar.host.url=http://ubsbase3:9090/sonar/

Et les informations de connexion à notre base de données. Tout d’abord, la chaîne de connexion composée de l’indication du pilote JDBC, notre serveur (ubsbase3.ubs-bi.local) et la base de données sonar sur le port par défaut 3306 de MySQL.

#----- MySQL
sonar.jdbc.url=jdbc:mysql://ubsbase3:3306/sonar?useUnicode=true&characterEncoding=utf8

Ensuite, l’indication du utilisateur MySQL avec son password, afin d’accéder à la base de données sonar.

sonar.jdbc.username: sonar
sonar.jdbc.password: s0n@r

Et voilà. Pour lancer le SonarQube Runner, il suffit d’utiliser le fichier sonar-runner.bat qui se trouve dans le répertoire ..\bin. Ce que nous allons voir avec notre première analyse SonarQube, dans le prochain post.

Il faut recopier le contenu du répertoire \UBS\outils\sonar-runner-2.4 sur UBSRDS3 dans le répertoire \UBS\outils\sonar-runner-2.4 sur le serveur UBSBASE3 afin que cette partie cliente soit accessible au plugin SonarQube pour Jenkins installé sur le serveur UBSBASE3.

Analyse avec SonarQube Runner

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=

et la modifier de façon à indiquer un sous-répertoire sonar du répertoire Mes Documents de l'utilisateur courant dans lequel nous placerons les fichiers de configuration de nos analyses.

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=\\ubsbase3\documents$\%USERNAME%\Mes documents\sonar
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 Mes documents\sonar créé précédemment. Il faut y recopier le contenu du répertoire SonarSource-sonar-examples\projects\languages\java\sonar-runner\java-sonar-runner-simple issu du téléchargement depuis http://docs.codehaus.org/display/SONAR/SonarQube+Project+Examples et de la décompression des exemples de SonarQube afin de récupérer un exemple de code et sa configuration d’analyse. Notre objectif est d’analyser une application Java localisée dans un répertoire \\ubsbase3\documents$\mdubois\Mes documents\sonar\src.

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=java-sonar-runner-simple
sonar.projectName=Simple Java project analyzed with the SonarQube Runner
sonar.projectVersion=1.0
  • Et bien sûr, l’emplacement des fichiers à analyser :
# Comma-separated paths to directories with sources (required)
sonar.sources=\\\\ubsbase3/documents$/mdubois/Mes documents/sonar/src

On remarque que le chemin à préciser est à la manière java. Comme le répertoire st un répertoire partagé sur le réseau il débute forcément par \\ mais en java il faut doubler chaque \. Pour éviter de doubler les autres caractères \, on emploie des / à leur place dans le chemin.

  • Dernier paramètre : le langage de programmation qui décidera du parseur SonarQube pour analyser cette application :
#The value of the property must be the key of the language.
sonar.language=java

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 sonar, ainsi que le fichier de configuration de notre analyse :

Exécution Sonar Runner

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.

SonarRunnerExec2

Lorsque vous verrez dans le log d’analyse, le message ANALYSIS SUCCESFULL : SonarRunnerExecFin

vous pouvez consulter le portail SonarQube et voir s’afficher les résultats de votre première analyse.

1ère analyse avec Sonar Runner

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.

Installer Jenkins sur le serveur UBSBASE3

Jenkins est un outil open source d'intégration continue, fork de l'outil Hudson après les différends entre son auteur, Kohsuke Kawaguchi, et Oracle. Écrit en Java, Jenkins fonctionne dans un conteneur de servlets tel qu’Apache Tomcat, ou en mode autonome avec son propre serveur Web embarqué.Il s'interface avec des systèmes de gestion de versions tels que CVS, Git et Subversion, et exécute des projets basés sur Apache Ant et Apache Maven aussi bien que des scripts arbitraires en shell Unix ou batch Windows.Les générations de projets peuvent être initiées par différents moyens, tels que des mécanismes de planification similaires au cron, des systèmes de dépendances entre générations, ou par des requêtes sur certaines URL spécifique. Jenkins est très fortement intégré à Apache Maven.

Open-Source, Plus de 500 plug-ins; Les fonctionnalités de Jenkins sont :

  • Déclencheur de build ;
  • Récupérer les sources d'un gestionnaire de source ;
  • Automatiser les build et les tests
  • Générer des rapports et notifier
  • Déployer le build
  • Installer le build sur un serveur de qualification

Au niveau des déclencheurs de build :

  • manuel
  • Périodiquement,
  • Après le build d'un projet
  • Lors du changement sur le gestionnaire de source

Jenkins permet d'utiliser CheckStyle, PMD (taille du code, complexité cyclomatique du code, proposition de solution d'optimisation et il signale le code inutilisé), Findbugs (code qui ne sera jamais exécuté, boucles infinies, détection des potentiels NullPointerException, vulnérabilité du code, performances / usage de la mémoire), EclEmma ou JaCoCo pour Java Code Coverage (ne contrôle pas la pertinence des tests, donne un indicateur sur les branches non testées) via des plugins.

Installation et première exécution et paramétrage de la JVM de Tomcat

Tout comme pour SonarQube, nous avons choisi d’installer Jenkins sous la forme d’un fichier .war, que nous téléchargeons depuis la page d’accueil de Jenkins, et à déployer sous Tomcat par recopie dans le répertoire \UBS\serveurs\UBS-OS-GISBI-Server\tomcat\webapps.

Le serveur Apache Tomcat va alors déployer ce fichier .war dans une webapp, à laquelle nous pouvons ensuite accéder depuis notre navigateur, avec l’URL suivante http://ubsbase3:9090/jenkins/.

Bien. Allons jeter un coup d’œil à la configuration de Jenkins, depuis le menu / le lien d’administration (Administrer Jenkins).

Vous verrez s’afficher la cause de l’erreur avec un message java.lang.OutOfMemoryError: PermGen space au niveau des logs ou de la console du serveur Apache Tomcat.

Sans rentrer dans les détails, le PermGen space est l’espace mémoire réservé au stockage des classes et des informations associées.

Nous allons donc résoudre ce problème de la manière suivante:

  1. Dans le répertoire \UBS\serveurs\UBS-OS-GISBI-Server\, rechercher le fichier start-pentaho.bat.
  2. Dans ce fichier, rechercher la ligne set CATALINA_OPTS=-Xms256m -Xmx768m -XX:MaxPermSize=256m et modifiez là comme ceci :
set CATALINA_OPTS=-Xms256m -Xmx768m -XX:MaxPermSize=512m 

Redémarrer le serveur Tomcat via stop-pentaho.bat puis start-pentaho.bat

Configuration de Jenkins

Dans la page d’administration, un message m’avertit que le conteneur de servlets – c’est à dire Tomcat – n’est pas à la norme UTF8, ce qui pourrait poser problèmes avec des caractères non ASCII (comme c’est le cas en Espagne par exemple).

Nous allons donc résoudre ce problème de la manière suivante:

  1. Dans le répertoire \UBS\serveurs\UBS-OS-GISBI-Server\tomcat\conf, rechercher le fichier server.xml.
  2. Dans ce fichier, rechercher la section Connector et insérer la ligne suivante :
URIEncoding="UTF-8"

Voici à quoi cela ressemble dans mon fichier :

Redémarrer le serveur Tomcat et vérifiez que le message d’erreur a disparu de la page d’administration de Jenkins.

Depuis cette page Administration (menu Administrer Jenkins), allons voir maintenant les paramètres de configuration, en sélectionnant le premier menu de cette page (Configurar El Sistema).

La première ligne dans cette page de configuration nous indque que Jenkins s’est installé dans un répertoire C:\.jenkins. Cela ne me convient pas du tout. Je souhaite centraliser tout ce qui touche à mes analyses dans un répertoire \UBS\jenkins_repository (par exemple). Il me faut donc pour cela modifier le paramètre de localisation du repository Jenkins.

Nous devons pour cela spécifier la variable JENKINS_HOME, de la manière suivante : dans le répertoire \UBS\serveurs\UBS-OS-GISBI-Server\tomcat\conf, localiser le fichier context.xml et insérer la ligne suivante :

<Environment name="JENKINS_HOME" value="/UBS/jenkins_repository/" type="java.lang.String"/>

Choisissez bien le répertoire où vous souhaitez localiser le repository Jenkins : si vous modifiez celui par la suite, vous perdrez la configuration existante (sauf à déplacer votre repository actuel vers le nouvel emplacement) et donc tout ce que vous avez pu installer, comme par exemple le plugin SonarQube pour Jenkins.

Installer le plugin SonarQube pour Jenkins sur le serveur UBSBASE3

Commençons d’abord par lancer Jenkins, c’est-à-dire l’application web correspondante sous Tomcat (http://ubsbase3:9090/jenkins/ dans mon environnement).

Dans la page d’administration de Jenkins, activer le menu de gestion des plugins.

Dans la page suivante, sélectionner l’onglet des plugins disponibles :

Rechercher puis sélectionner le plugin SonarQube. Je vous conseille d’effectuer une recherche sur la chaîne de caractères Sonar afin de trouver plus rapidement le plugin dans cette liste particulièrement longue.

En bas de page, activer le bouton Installer sans redémarrer :

Jenkins lance l’installation et, une fois celle-ci terminée…

… , nous avertit que le plugin SonarQube a été installé. Nous pouvons revenir dans la page d’administration de Jenkins afin de sélectionner le menu de configuration, qui va nous permettre de paramétrer notre installation SonarQube.

Configuration du SonarQube Runner

Jenkins va utiliser le SonarQube Runner (que nous avons installé précédemment).

Afin de configurer celui-ci, nous retournons dans la page d’administration de Jenkins afin d’activer le menu de configuration de celui-ci.

Remarquez dans cette page la première ligne qui indique le répertoire de travail de Jenkins, que nous avons configuré précédemment.

Plus bas, Jenkins nous permet de configurer ou voire même d’installer un JDK.

Si nous vérifions dans le répertoire d’installation C:\Program Files\Java du server UBSBASE3, nous avons :

  • Un sous-répertoire jdk1.6.0_43, avec le JDK.
  • Un sous-répertoire jre6, avec la JVM qui va nous permettre d’exécuter des programmes Java.

Comme un JDK 32 bits est aussi installé, il se trouvera dans le répertoire C:Program Files (x86)\Java.

Ce n’est pas nécessaire si vous avez créer une variable JAVA_HOME avec l’indication, dans la variable PATH de la machine, du répertoire contenant les exécutables du JDK. La mise à jour de ces variables aussi être faite dans le script de lancement du serveur Apache Tomcat (\UBS\serveurs\UBS-OS-GISBI-Server\start-pentaho.bat).

set JAVA_HOME="C:\Program Files (x86)\Java\jdk1.6.0_43"
set PATH=%JAVA_HOME%/bin;%PATH%

En dessous, une section consacrée au SonarQube Runner va nous permettre de configurer celui-ci pour Jenkins. Tout d’abord, cliquer le bouton qui permet d’ajouter une instance de SonarQube Runner :

Ce qui aura pour effet d’ouvrir la section de configuration de celui-ci :

Dans cette section:

  • Décocher la check-box d’installation automatique.
  • Donner un nom à votre instance de SonarQube Runner.
  • Indiquer la localisation de celui-ci.

Et finalement, n’oubliez pas de sauvegarder vos paramètres. C’en est fini.

Configuration de SonarQube

La configuration de SonarQube dans Jenkins va suivre la même logique. Toujours dans cette même page de configuration du système Jenkins, repérez la section consacrée à SonarQube :

Comme auparavant, cliquer sur le bouton qui permet de créer une nouvelle instance de SonarQube.

Jenkins nous demande alors de saisir un nom afin d’identifier notre installation de SonarQube.

Ensuite seulement, vous pouvez cliquer le bouton Avancé… afin d’ouvrir une page qui va nous permettre d’indiquer les différents paramètres de configuration.

Ceux-ci sont les mêmes que ceux indiqués dans le fichier sonar-properties de SonarQube. Il suffit donc d’ouvrir ce fichier pour reprendre ces mêmes paramètres :

Nous indiquons donc :

  • L’URL de notre application web SonarQube :http://ubsbase3:9090/sonar/.
  • L’adresse de notre base de données :jdbc:mysql://ubsbase3:3306/sonar?useUnicode=true&characterEncoding=utf8 (ne pas faire précéder par sonar.jdbc.url=), contrairement à ce qui est montré à l'écran.
  • Le driver JDBC pour accéder à la base de données :com.mysql.jdbc.Driver.

J’ai indiqué également l'utilisateur MySQL et son password, pour accéder à la base de données Sonar. Je n’ai pas indiqué de user SonarQube pour effectuer les analyses, puisque je ne l’avais pas fait non plus lors de l’installation du SonarQube Runner.

N’oubliez pas de sauvegarder les paramètres saisis à l’aide du bouton situé en bas de page.

Analyse SonarQube avec Jenkins

Nous allons faire 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.

Jenkins nouveau projet

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 Item : 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 Construire un projet free-style et entrer un nom de projet : Simple Java project analyzed with the SonarQube Runner from Jenkins plugin dans notre exemple. Le bouton Ok en fin de page devient actif.

Page de projet Jenkins

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.

JenkinsStandalone

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 étape au build qui ouvre la liste de menus suivante dans laquelle nous choisissons Lancer une analyse Sonar autonome.

Ceci nous ouvre la page de configuration pour ce projet :

JenkinsProjectDetails

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 partagé \\ubsbase3\documents$\mdubois\Mes documents\sonar ou D:\Documents\mdubois\Mes documents\sonar (chemin local à UBSBASE3).

Et dans ce billet, 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.

# Required metadata
sonar.projectKey=java-sonar-jenkins-runner-simple
sonar.projectName=Simple Java project analyzed with the SonarQube Runner from Jenkins plugin
sonar.projectVersion=1.0

# Comma-separated paths to directories with sources (required)
sonar.sources=D:/Documents/mdubois/Mes documents/sonar/src

# Language
sonar.language=java

# Encoding of the source files
sonar.sourceEncoding=UTF-8

On remarque que le chemin des fichiers sources est différent dans la mesure ou le sonar Runner s'exécute sur le serveur UBSBASE3. Le répertoire partagé D:\Documents\ sur serveur UBSBASE3 est accessible depuis UBSRDS3 par le chemin \\ubsbase3\documents$\. Comme le répertoire partagé fonctionne aussi depuis UBSBASE3, il n'est pas nécessaire de changer de fichier properties.

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 billet 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.

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

Mettre en place Sonar pour un projet .NET et comment l’intégrer à un build TFS 2010

http://blog.loftdigital.com/posts/jenkins-ci-and-php

Vers le déploiement continu :

  • Pouvoir définir une release candidate
  • Installation automatisée en production
  • Possibilité de faire marche arrière
  • Green server / Blue Server

Comments

  1. By gagnerdelargent.tv, on January 20, 2016, at 09:59 PM
    On en veux plus !!! chez moi vous etes maintenant dans mes preferences, a bientot.
  2. By gagnerdelargent.tv, on February 06, 2016, at 02:20 PM
    Dire que je ne connaissait pas votre site, vous voila bookmarker !
  3. By gagnerdelargent.tv, on February 13, 2016, at 05:34 PM
    C est un veritable plaisir de lire ce billet, je vous en remercie vraiment !!!
  4. By gagnerdelargent.tv, on February 15, 2016, at 02:23 PM
    J'espere que vous avez d autre article de cette trempe en stock !
  5. By Robin, on August 30, 2017, at 03:41 PM
    Bonjour,
    Très intéressant!
    J'aimerai savoir si lors du build "Lancer une analyse sonar autonome" Jenkins générait un .war et si oui dans quel repertoir il le deposait?
    Merci par avance.

Leave a comment

All comments are reviewed before being displayed.


Name (required):

E-mail (required, will not be published):

Website:

Enter value: