Le SonarSource City Tour 2016 est passé par Paris le 13 septembre 2016. Passionné de DevOps et convaincu de la pertinence de l’intégration continue, l’occasion était parfaite pour se rendre à l’événement.
Le circuit passe par 12 villes dont Santa Clara, New York, Francfort, Londres, etc. Arrivée un peu plus à mi-parcours, Paris est la ville qui accueille le plus de curieux avec plus de 120 personnes présentes. Parmi les orateurs SonarSource présent, Olivier Gaudin, Freddy Mallet, Fabrice Bellingard, Nicolas Peru ont été les plus actifs.
Outil populaire
D’abord grand fan de PMD, Findbugs et Checkstyle depuis mes jeunes années de développeur Java, je dois reconnaître que l’association de SonarQube avec Jenkins en a fait une référence, un standard de fait. C’est un acteur de premier plan dans une usine à build. L’outil est populaire. Les organisateurs avancent même le chiffre de 80 000 entreprises utilisatrices (volume mesuré par l’update center).
Quelle approche pour faire de la qualité ?
La qualité intéresse-t-elle tout le monde ? De la même manière que l’écriture des tests, la plupart du temps elle est massacrée ou simplement ignorée. Dans la précipitation et l’urgence des livraisons, on remets toujours à demain, la revue de code n’est pas prioritaire.
Une fois le legacy existant que faire ? Confier le projet à une équipe d’audit ? ils devront sermonner les développeurs, qui traîneront des pieds pour corriger. Alors on nomme d’office une équipe pour corriger la dette : elle est en charge de fixer les violations les plus sévères , ils tenteront de dépiler la longue liste de bugs bloquants, puis critiques.. ils abandonneront avant : l’exercice est très délicat, très rébarbatif, pas amusant du tout. Sans parler du risque de casser quelque chose.
Olivier Gaudin insiste : l’équipe de dev doit être responsable, fournir un livrable qui répond déjà aux critères de qualités. Attendre la release pour analyser c’est trop tard. En fait le feedback doit être le plus court possible. Il faut gérer la fuite au fur et à mesure qu’elle se déclare. C’est la fameuse image de la fuite d’eau, le waterleak http://docs.sonarqube.org/display/HOME/Fixing+the+Water+Leak l’idée est de se focaliser sur le robinet qui fuit (donc le nouveau code) et après nous irons éponger l eau sur le sol (le code legacy). En effet l’eau déjà répandue peut attendre alors qu’il y a urgence sur le robinet. S’acharner à éponger l’eau est une perte de temps ! C’est du code déjà existant, déjà en prod, alors laissons le là où il est. Intercepter la fuite, c’est facile, c’est frais, c’est dans les têtes, une nouvelle dette est très peu chère à corriger. Personne n’ira grogner pour colmater la fuite, corriger son code. On peut même parier que ce sera fixé sans soucis, en un temps record, et surtout avec un coût humain négligeable ! La responsabilité devient claire. la patate chaude n’est plus.
Nouveautés de la version 5.6
Comment la fuite est elle mesuré ? Qu’est ce qui distingue concrètement la flaque déjà répandu de l’urgence de la fuite ? En fait, le nouveau code est mesuré à partir d’une version de son choix, une date précise, ou juste depuis la dernière analyse complète.
Dans cette optique, le nouveau tableau de bord SonarQube 5.6 présente des métriques uniquement axées sur le ‘nouveau’ code. La visibilité est immédiate, vous savez si la version en cours introduit de la dette. Nombre de nouveaux bugs, couverture de code sur le ‘nouveau code’, etc. Poussant ce raisonnement plus loin, la pyramide de dettes technique, présente encore sur la dernière version, en a fait les frais, elle a disparu. Ce widget est devenu trop généraliste, trop focussé sur la dette ‘en général’, il ne correspond plus à la nouvelle approche ‘leak’. Petite déception tout de même pour ma part.
Autre absent, le plugin ‘views’ : il permettait d’agréger les indicateurs de plusieurs projets en un seul. Une façon de voir comment son parc évolue. En fait il est remplacé par un nouveau plugin ‘Governance’. http://www.sonarsource.com/products/plugins/governance/ Mais pour cela il faut posséder la version ‘Entreprise’ de SonarQube, autrement dit là où une DSI pouvait utiliser la version communautaire de SonarQube (donc gratuite) et juste financer le plugin ‘views’,elle devra à présent acheter la version ‘entreprise’ à un coût nettement plus élevé. L’annonce a plutôt choqué l’auditoire.
SonarQube 5.6 arrive aussi avec son lot de nouveautés techniques : la connexion directement à la base de données n’existe plus. Pour des raisons de sécurité déjà, les “clients” ne portent plus avec eux les credentials de la base de données. Les communications se font par webservice. C’est l’instance du serveur SonarQube qui gère les lectures et écritures en base. Ensuite, pour des raisons de performances : imaginons plusieurs serveurs jenkins qui remontent dans un laps de temps très serré un nombre élevé de rapports d’analyse : la base de données va se retrouver sous l’eau, entraînant des retards dans les consultations de page sur l’ihm. Avec la version 5.6 c’est le ‘Compute Engine’ qui prend le temps de digérer les rapports reçus par webservice et d’injecter les données dans la base de données, de ce fait la communication avec le client ayant soumis le rapport est asynchrone, soulageant le client de l’attente de la fin du traitement.
En plus de cela, pour accélérer les temps de réponses, Elasticsearch est maintenant de la partie. Il indexe les erreurs et permets de gros gains dans les affichages de détail de classe et lors de recherche de modules, sous modules ou de classes.
En contrepartie, SonarQube 5.6 est plus gourmand, il y a 3 process java à présent (serveur web, ComputeEngine, Elasticsearch) contre un seul auparavant.
Citant la roadmap à venir, Julien Peru est clair : SonarQube doit pouvoir scaler horizontalement, car la verticale a une limite: demain on doit pouvoir étendre sur l horizontal, répartir la charge, avoir plusieurs Compute Engine si on le souhaite, plusieurs Elasticsearch, plusieurs serveurs web, plusieurs bases de données. Un serveur classique même gonflé ne suffit plus. L’éditeur est directement concerné par ce besoin de scalabilité, car il héberge gratuitement les analyses des produits open source : https://sonarqube.com/
A noter l’intervention de Jean Marc Prieur, Program Manager chez Microsoft, qui a permis la coopération entre la firme de Richmond et SonarQube pour rendre possible une analyse sonar sur la plateforme microsoft Azure.
Quelle approche pour écrire de la qualité ?
Il existe 3 niveaux de retour d’analyse du code par SonarQube, ce qui permet d’entrevoir autant de scénarios :
- 1er niveau : dans le flow de développement.
Freddy Mallet explique que le retour immédiat passe par l’utilisation de Sonar Lint http://www.sonarlint.org/, un plugin pour Eclipse, intelliJ et VisualStudio.
L’utilisation est très simple : votre code (html, javascript, css, java, .) est de suite analysé dans votre IDE à chaque enregistrement, soulignant les lignes ne répondant pas au niveau de qualité requis. Le plugin peut même être connecté à l’instance SonarQube appliquant ainsi le profil qualité de votre choix, telle qu’il est défini sur le serveur. Ainsi tous les développeurs traquent la dette en temps réel, elle n’a alors en principe que très peu temps à vivre, le feedback est immédiat.
- 2eme niveau : dans les pull request
Si malgré tout, du code de mauvaise qualité venait à être poussé sous Git, SonarQube peut être relié aux pull request, présentant ainsi lors du code review sous votre interface Github les parties de code défaillantes.http://www.sonarqube.org/github-pull-request-analysis-helps-fix-the-leak/
En plus de GitHub , il existe un plugin pour Bickbucket https://github.com/AmadeusITGroup/sonar-stash présenté durant cette même journée par Antoine Copet de l’entreprise Amadeus.
- 3eme niveau : l’analyse ‘full’
C’est l’analyse ‘complète’ et la plus connue, qui parse le projet dans sa globalité. Pouvant prendre plusieurs heures et gourmand en ressource il est préférable de l’exploiter sous forme de bilan qui tournerait une fois par nuit, par exemple via un job jenkins réglé par un cron. Dans ce cas là le retour se fait par consultation du dashboard SonarQube, les développeurs perdent en efficacité.
Et les règles ?
Chez SonarQube la moitié des équipes de dev travaillent sur les analyses de code, l’accent étant porté actuellement sur les langages C, C#, C++ et Javascript.
Fabrice Bellingard nous explique qu’une règle c’est une implémentation mais aussi une documentation: pourquoi cette erreur, pourquoi cet endroit, comment corriger.
A ce propos j’insiste à titre personnel sur le fait que développer avec les règles SonarQube et auparavant avec Pmd et findbugs m’ont permis d’apprendre énormément sur les bonnes pratiques, un peu comme si j’avais eu un coach à mes côtés. C’est fun et pédagogique.
Les règles implémentés dans SonarQube ne sont pas là par hasard, elles sont issues d’organismes de références tels CWE, CERT et OWASP.
Elles sont regroupées dans le JIRA https://jira.sonarsource.com/browse/RSPEC/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel .
La mailling liste SonarQube est ouverte pour recevoir les avis, demandes et critiques sur les règles.
https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards
https://www.owasp.org/index.php/OWASP_SonarQube_Project
Nicolas Peru nous rappelle que SonarQube est un outil d’analyse de code statique, on y distingue 3 niveaux d’analyses :
lexical (suite de mots ou présence de mots )
syntaxique (un sujet, un verbe)
A ce stade beaucoup de règles peuvent exister.
Le dernier niveau, l’analyse sémantique, est la plus gourmande : tous les chemins d’exécutions sont parcourus, pas à pas chaque variable est suivie. On identifie ainsi par exemple les risques de Null Pointer Exception, les conditions qui ne servent à rien, les divisions par zéro, ..
Par contre cette analyse ne suit pas les variables entre les appels de méthodes. (ce qui est prévu dans la roadmap)
Le futur
Des outils comme checkmarx qui traquent les failles de sécurité devraient être à terme intégrés dans le moteur SonarQube. (Avec un moteur et une analyse pur jus SonarQube)
Une meilleur la gestion des branches : aujourd’hui un projet github qui comporte plusieurs branches a pour conséquences d’avoir autant de projet dans SonarQube ce qui demande de dupliquer les configurations. Il faut aussi utiliser un paramètre sonar.branch pour distinguer la branche du master et ainsi s’assurer que les analyses ne remontent pas sur le projet principal. Ce point fait partie des tâches prioritaires pour les évolutions à venir.
A noter que la dernière version de SonarQube propose une API REST toujours plus riche. L’interaction dans un environnement d’intégration continue en est renforcée, exploitable par exemple dans des scripts shell ou groovy ou bien des plugins java. https://sonarqube.com/web_api
Conclusion
SonarQube devient encore un peu plus un élément central dans l’intégration continue. La qualité est maintenant concevable directement depuis l’IDE sans attendre les rapports colossaux indigestes. La productivité se retrouve grandie et coder reste fun. En outre L’API REST permet à SonarQube d’interagir avec les autres acteurs de l’usine logicielle et de ne pas l’isoler à un simple rôle du ‘catalogue des bugs’.
Merci à SonarQube pour cette journée enrichissante et à Fabrice Bellingard pour sa disponibilité pour mes différentes questions.
