Dernier post de notre série sur l’analyse de la qualité du code PL/SQL avec SonarQube.

Evaluer la qualité d’une application ne consiste pas uniquement en l’analyse du code : cela, n’importe qui peut le faire. Le travail du consultant Qualité s’articule autour des questions suivantes : quoi, pourquoi, comment, combien.

• Quoi : analyser les résultats. Taille et complexité du code, duplications, c’est ce que nous avons vu dans les posts précédents. On examinera les chiffres globaux mais aussi les moyennes, ainsi que les tendances dans le temps si l’on dispose de plusieurs versions. Puis on regarde les principales violations aux bonnes pratiques, en s’intéressant en priorité aux Blockers et Criticals.
• Pourquoi ces résultats : rechercher les causes des mesures analysées, investiguer l’origine des résultats rencontrés.
• Comment remédier : proposer un plan d’action. En fait, réaliser plusieurs propositions de plan d’action. Nous verrons ci-dessous que je décline ceux-ci en différents plans à court, moyen et long terme.
• Combien cela coûte : évaluation du coût de chaque plan. Continuer la lecture →

Désolé de vous avoir fait attendre pour la suite de cette série sur le code PL/SQL et SonarQube, mais j’ai été pas mal occupé, entre voyages, travail et mon portable qui m’a lâchement abandonné, en invoquant bien évidemment la loi de Murphy pour justifier de tomber en panne au pire moment.

Rappel sur les posts précédents : après avoir configuré une analyse de code PL/SQL avec SonarQube, nous avons constitué notre propre Quality Profile en orientant les règles Blockers et Criticals sur la robustesse, la performance et la sécurité. A quoi ressemble maintenant notre tableau de bord ? Continuer la lecture →

Un post en guise de synthèse, pour cette série sur l’analyse de code PL/SQL avec SonarQube.

Après avoir configuré notre analyse avec Jenkins, nous avons lancé celle-ci et constaté 17 infractions bloquantes (Blockers) mais zéro défaut critique (Critical) avec le Quality Profile par défaut de SonarQube. En fait, les 5 règles Critical existantes étaient désactivées, ainsi que certaines des autres règles de différentes criticités : 58 sur un total de 132. Continuer la lecture →

Nous continuons cette série sur l’analyse de code PL/SQL, avec aujourd’hui les règles de type Major.

Nous avons vu précédemment comment organiser notre environnement et configurer notre analyse de code avec Jenkins et SonarQube.

Nous avons créé notre propre Quality Profile, puis examiné les règles de type Blockers et Criticals, toutes orientées Robustesse (Reliability) et Sécurité. Continuer la lecture →

Dans le post précédent de cette série sur l’analyse de code PL/SQL avec SonarQube, nous avons examiné les régles Blockers existantes dans notre Quality Profile.

Nous avons rencontré à cette occasion 3 violations aux ‘best practices’ de programmation PL/SQL dont les conséquences sont d’une gravité telle qu’aucune tolérance n’est envisageable pour celles-ci. Ce qui justifie donc leur statut de ‘Blockers’.

Nous avons également constaté un total de 18 défauts pour ces 3 règles, donc ce nombre limité nous laisse supposer que celles-ci sont connues de l’équipe de projet

Enfin, ces défauts ont pour conséquence un bug de logique applicative dans l’application – une opération qui ne sera jamais effectuée car la condition correspondante ne sera jamais rencontrée – voire un crash pur et simple. Continuer la lecture →

Dans le post précédent, nous avons créé notre propre Quality Profile PL/SQL en activant toutes les règles existantes dans SonarQube, au nombre de 132. Puis nous avons ensuite relancé l’analyse créée précédemment.

Nous allons ainsi pouvoir travailler avec l’ensemble des règles du Quality Profile par défaut de SonarQube et sélectionner celles qui nous intéressent afin de créer un tableau de bord ‘PL/SQL’ pour notre environnement de démo. Continuer la lecture →

Après avoir configuré notre première analyse PL/SQL depuis Jenkins, nous avons lancé celle-ci, et nous pouvons donc maintenant regarder les résultats dans le tableau de bord SonarQube.

Ceci sera l’occasion d’examiner et d’expliciter dans nos prochains posts, les règles proposées par SonarQube en matière de bonnes pratiques de programmation PL/SQL. Mais tout d’abord, regardons ce que nous propose le ‘profile’ PL/SQL de SonarQube. Continuer la lecture →

Nous avons vu, dans le premier post de cette série sur l’analyse de code PL/SQL avec SonarQube, comment j’organise mon environnement d’analyse, avec :

• un dossier C:\SRC\ contenant tous les projets,
• un sous-répertoire dédié au projet,
• différents sous-répertoires dont un ‘..\Source’ avec le code source à analyser.

Dans le cas de notre analyse PL/SQL, ce code se trouvera donc dans un dossier ’C:\SRC\Demo\PLSQL\Source’.

Voyons maintenant comment créer et configurer une analyse SonarQube de ce code, avec Jenkins. Continuer la lecture →

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. Continuer la lecture →