Maintenant que j’ai mis à jour mon environnement d’analyse de code au complet, avec les upgrades de SonarQube, du SonarQube-Runner et de Jenkins dans leurs dernières versions, le moment est venu de mettre à jour également mon repository d’applications et mes démos.

En tant que Consultant Qualité, j’ai toutes sortes de ‘projets’, c’est-à-dire d’analyses de code source, répondant à divers types de processus Qualité (Continuous Integration, Quality Gate, Quality Assessment, etc.) et ce pour tous types de technologies. Rappelons que SonarQube n’est pas juste un outil Open Source qui analyse du Java ou des languages de programmation objet : il est aussi très utile pour des applications Legacy Cobol, SAP-ABAP, client-serveur, etc.

J’ai donc décidé de mettre à profit la relative baisse d’activité de fin d’année pour faire le ménage dans mes démos … en commençant par le PL/SQL. Au fil du temps, j’ai amassé toutes sortes de scripts de création de base de données, ou de programmes de traitement de bases de données, et nous allons en profiter pour :

• Rappeler comment, en tant que Consultant Qualité, j’organise mon environnement d’analyse de code.
• Paramétrer et effectuer une analyse PL/SQL avec SonarQube.
• Voir comment personnaliser le profile de règles PL/SQL fourni par SonarQube.
• Examiner plus en détail les diffèrentes règles et métriques de bases de données proposées par SonarQube, et comment les utiliser.

Je ne sais pas encore combien de posts seront nécessaires pour couvrir ce thème ‘SonarQube et PL/SQL’, j’ai tendance à les écrire au fur et à mesure de mes pérénigrations dans l’outil et j’aime laisser un peu de marge à l’improvisation. De plus, il me faudra probablement interrompre cette série pour un post consacré aux vœux de nouvelle année (et des fêtes en famille), donc il est probable que cela nous emmènera jusqu’en Janvier.

Organisation de l’environnement d’analyse

Tout d’abord, quelques rappels sur la manière dont j’ai organisé mon environnement d’analyse de code source. Il n’est évidemment pas absolument indispensable de procéder de même, mais je vous recommande néanmoins d’adopter un minimum de règles d’organisation.

Notamment si vous travaillez en équipe. Vous n’avez pas envie qu’on vous appelle pendant les vacances parce que personne n’est capable de reprendre cet audit de code que vous n’avez pas pu terminer à cause du retard pris par le client pour livrer à temps le code de son application. Et le pauvre malheureux qui doit continuer cette tâche ne sait pas comment vous avez l’habitude de travailler, comment vous configurer une analyse, si vous utilisez des règles ou métriques particulières, etc.

Et même si vous travaillez seul, comme moi en freelance par exemple, il reste souhaitable de toujours suivre les mêmes processus, au risque de ne pas vous rappeler oú diable vous avez gardé ce fichier de configuration de cette analyse, menée il y a 2 ans, et que vous aimeriez retrouver maintenant.

Enfin bref, voici comment je travaille, sur mon portable :

• Un répertoire dédié à mon environnement d’analyse ‘C:\SRC’.
• Divers sous-répertoires organisés essentiellement par technos (J2EE, ABAP, Cobol, Repository des autres technos, …) et surtour un dossier consacré exclusivement à mes démos : ‘C:\SRC\Demo’.
• Au sein de ce dossier, un sous-répertoire par technologie :‘C:\SRC\Demo\J2EE’, ‘C:\SRC\Demo\Cobol’,  …, ‘C:\SRC\Demo\PLSQL’ pour notre démo consacré au language de programmation de traitements de base de données Oracle.

Au sein de chaque dossier, j’utiliser 3 sous-répertoires :

• ‘Delivery’ pour stocker les versions d’applications qui me sont livrées pour audit.
• ‘Conf’ pour gérer tous les fichiers de configuration, documentations du client, documents d’analyse, rapport d’audits, feuilles de calcul, présentations, etc.
• ‘Source’ pour copier le code à analyser.

Pourquoi ne pas disposer d’un répertoire unique pour analyser une version ? D’abord parce que je peux avoir plusieurs versions successives à analyser. Par exemple, un client souhaite un audit car il n’est pas très content de son outsourceur et aimerait vérifier la qualité du code que celui-ci lui fournit. Nous allons d’abord analyser la version initiale confiée pour maintenance à cet outsourceur, puis la version finale que celui-ci a retournée au client. En analysant ces deux versions successivement, nous pourrons déterminer les différences – pour le meilleur ou pour le pire – en termes de défauts, de complexité et de maintenabilité, entre ces deux versions.

Mais surtout, il peut m’arriver de devoir transformer le code livré par le client, pour différentes raisons :

• Un fichier pose un problème au parser qui stoppe l’analyse. Par exemple, la version livrée par le client contient un vieux programme, qui n’est plus utilisé, mais qui ne compile pas non plus.
• Je dois réorganiser le code différemment. Incroyable le nombre d’architectes ‘Nouvelles-Technologies’ qui ont réinventé les bonnes pratiques en matière d’organisation de packages et de répertoires.
• La livraison contient une foultitude de répertoires .svn qui évidemment occupent de l’espace disque dur mais aussi ralentissent les analyses.

Si vous disposez d’un serveur, je vous recommande d’utiliser un disque dur pour vos softwares et le disque dur le plus performant pour stocker le code source et effectuer vos analyses.

Bien sûr, si vous travaillez au sein d’une équipe de projet, vous disposez certainement d’un outil de gestion de configuration (SCM) et donc votre environnement sera différent. Retenons simplement que  mon répertoire d’analyse de code PL/SQL sera : ‘C:\SRC\Demo\PLSQL\Source’.

Le prochain post sera consacré à la configuration de cette analyse.

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.