Nous souhaitons partager notre expérience d'intégration de la plateforme d'analyse continue et de mesure de la qualité du code SonarQube dans les processus de développement du système DPO (complément au système de comptabilité des dépôts et des compensations « Alameda ») du Dépositaire national de règlement.
Le Dépositaire national de règlement (groupe de sociétés « Bourse de Moscou ») est l'une des entreprises clés de l'infrastructure financière, conservant et comptabilisant des titres émis par des émetteurs russes et étrangers pour un montant supérieur à 50 trillions de roubles. L'augmentation des opérations réalisées par le système, ainsi que l'accroissement continu des fonctionnalités, nécessitent le maintien d'une haute qualité du code source des systèmes. L'un des outils pour atteindre cet objectif est l'analyseur statique SonarQube. Dans cet article, nous décrivons l'expérience réussie d'intégration transparente de l'analyseur statique SonarQube dans les processus de développement de notre département.
Brève présentation du département
Notre domaine de compétence inclut les modules suivants : paiements aux clients du NRD, circulation électronique des documents (CED), traitement des messages du dépositaire de négociation (enregistrement des transactions de gré à gré), canaux d'interaction électronique entre les clients et le NRD et bien d'autres encore. En somme, un vaste pan de travail sur l'aspect technique des opérations. Nous travaillons sur la base de demandes. Les demandes des opérationnels sont traitées par les analystes : ils collectent les exigences des clients et nous présentent leur vision de la façon dont cela doit être intégré dans le programme. Ensuite, le schéma standard : développement du code – test – exploitation expérimentale – livraison du code à l'environnement de production au client direct.
Pourquoi SonarQube en particulier ?
C'est la première expérience de notre département dans l'implémentation d'une plateforme pour le contrôle de la qualité du code – auparavant, nous le faisions manuellement, en procédant uniquement à des revues de code. Cependant, le volume croissant de travail nécessite l'automatisation de ce processus. De plus, il y a des employés peu expérimentés dans l'équipe, qui ne sont pas entièrement familiers avec les règlements internes de développement et ont tendance à faire plus d'erreurs. Pour le contrôle de la qualité du code, il a été décidé de déployer un analyseur statique. Comme SonarQube avait déjà été utilisé dans certains systèmes de la NRD, le choix n'a pas été long. Auparavant, des collègues d'autres départements avaient analysé le code de microservices dans le système « Alamedа » (système propre de comptabilité de dépôt et de compensation de la NRD), dans le CFT (système d'information pour la comptabilité, les bilans, et la préparation des rapports obligatoires et internes), et dans certains autres systèmes. Pour nos expériences, nous avons décidé de commencer avec la version gratuite de SonarQube. Passons à notre cas.
Processus d'implémentation
Nous avons:
- assemblage automatique du système dans TeamCity ;
- le processus de transfert de code via MergeRequest de la branche feature à la branche master dans GitLab est configuré (processus de développement selon le GitHub Flow) ;
- SonarQube, configuré pour analyser le code du système DPO selon un emploi du temps.
Notre objectif: intégrer l'analyse automatique du code dans les processus CI/CD du DPO.
Il faut configurer: le processus de vérification automatique du code par un analyseur statique à chaque MergeRequest dans la branche principale.
C'est-à-dire, le tableau cible est le suivant : dès qu'un développeur charge des modifications dans la branche feature, une vérification automatique est lancée pour détecter de nouvelles erreurs dans le code. S'il n'y a pas d'erreurs, les modifications peuvent être acceptées, sinon des corrections sont nécessaires. Dès le début, nous avons pu identifier un certain nombre d'erreurs dans le code. Le système a des paramètres très flexibles : il peut être configuré de manière à fonctionner pour des tâches spécifiques des développeurs, pour chaque système et style de programmation.
Configuration de QualityGate dans SonarQube
L'analyse QualityGate est un sujet que nous avons découvert dans les profondeurs d'Internet. Au départ, nous utilisions une autre approche, plus complexe et, d'une certaine manière, pas tout à fait correcte. Nous lancions d'abord deux analyses à travers SonarQube : nous analysions la branche feature et la branche dans laquelle nous souhaitions fusionner la branche feature, puis nous comparions le nombre d'erreurs. Cette méthode manquait de stabilité et ne donnait pas toujours de résultats fiables. Ensuite, nous avons découvert qu'au lieu de faire deux analyses de SonarQube, il était possible de définir une limite sur le nombre d'erreurs autorisées (QualityGate) et d'analyser uniquement la branche que vous chargez et comparez.
Pour l'instant, nous utilisons encore une vérification de code assez rudimentaire. Il convient de noter que SonarQube n'est pas compatible avec certains langages de programmation, y compris Delphi. Actuellement, pour notre système, nous analysons uniquement le code PLSql.
Ça fonctionne comme ceci :
- Nous analysons pour notre projet uniquement le code PL/SQL.
- Le QualityGate dans SonarQube est configuré de telle manière que le nombre d'erreurs n'augmente pas avec le commit.
- Au premier lancement, nous avons obtenu 229 erreurs. Si le nombre d'erreurs lors du commit augmente, la fusion n'est pas autorisée.
- Ensuite, sous réserve de correction des erreurs, il sera possible de reconfigurer le QualityGate.
- De nouveaux critères d'analyse peuvent également être ajoutés, par exemple, la couverture du code par des tests, etc.
Schéma de fonctionnement :
Dans les commentaires du script, on voit que le nombre d'erreurs dans la branche feature n'a pas augmenté. Tout va bien.
Le bouton Merge devient disponible.
Dans les commentaires du script, on voit que le nombre d'erreurs dans la branche feature a dépassé la limite autorisée. C'est mauvais.
Le bouton Merge est rouge. Pour l'instant, il n'y a pas d'interdiction de fusionner des modifications avec du code erroné, mais cela se fait à la discrétion du développeur responsable. Par la suite, il sera possible d'interdire de tels commits dans la branche principale.
Auto-formation sur les erreurs.
Ensuite, il est nécessaire de vérifier toutes les erreurs identifiées par le système, car SonarQube analyse selon ses normes strictes. Ce qu'il considère comme une erreur ne l'est pas forcément dans notre code. Il est donc nécessaire de vérifier et de marquer si c'est vraiment une erreur, ou s'il n'est pas nécessaire d'apporter des modifications dans notre contexte. Cela nous permet de réduire le nombre d'erreurs. Au fil du temps, le système apprendra à comprendre ces subtilités.
Où en sommes-nous
Notre objectif était de comprendre s'il était judicieux dans notre cas de traduire la vérification du code en automatisation. Et le résultat a répondu à nos attentes. SonarQube nous permet de travailler avec les langages qui nous intéressent, effectue une analyse assez correcte et a le potentiel d'apprendre des suggestions des développeurs. Dans l'ensemble, nous sommes satisfaits de notre première expérience avec SonarQube et prévoyons d'évoluer davantage dans cette direction. Nous espérons qu'à l'avenir, nous pourrons économiser plus de temps et d'efforts sur la vérification du code et la rendre de meilleure qualité, en éliminant le facteur humain. Peut-être que pendant le processus, nous découvrirons des défauts de la plateforme ou, au contraire, nous confirmerons à nouveau que c'est une excellente chose avec un grand potentiel.
Dans cet article d'examen, nous avons parlé de notre rencontre avec l'analyseur statique SonarQube. Si vous avez des questions, n'hésitez pas à les poser dans les commentaires. Si ce sujet vous intéresse, dans notre prochaine publication, nous décrirons plus en détail comment tout configurer correctement et écrire du code pour effectuer ce type de vérification.
Auteur du texte :
Source : habr.com
