Nous souhaitons partager notre expérience de mise en œuvre d'une plateforme d'analyse et de mesure en continu de la qualité du code SonarQube dans les processus existants de développement du système DPO (un complément au système de dépositaire et de comptabilité de compensation Alameda) du National Settlement Depository.
Le National Settlement Depository (Moscow Exchange Group of Companies) est l'une des principales sociétés d'infrastructure financière qui stocke et enregistre les titres d'émetteurs russes et étrangers d'une valeur de plus de 50 XNUMX milliards de roubles. Le volume croissant d'opérations effectuées par le système, ainsi que l'augmentation continue des fonctionnalités, nécessitent de maintenir la 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 de la mise en œuvre transparente de l'analyseur statique SonarQube dans les processus de développement existants de notre département.
En bref sur le département
Notre compétence comprend les modules suivants : paiements aux clients de NSD, gestion électronique des documents (EDF), traitement des messages du référentiel central (enregistrement des opérations de gré à gré), canaux électroniques d'interaction entre les clients et NSD, et bien plus encore. En général, une grande couche de travail sur le côté technique des opérations. Nous travaillons sur dossier. Les candidatures des caissiers sont traitées par des analystes : ils recueillent les besoins des clients et nous présentent leur vision de la manière dont cela doit s'inscrire dans le programme. En outre, le schéma standard : développement de code - test - opération d'essai - livraison du code au circuit de production au client direct.
Pourquoi SonarQube ?
Il s'agit de la première expérience de notre département dans la mise en œuvre d'une plate-forme de contrôle de la qualité du code - auparavant, nous le faisions manuellement, uniquement la révision du code. Mais le volume croissant de travail nécessite une automatisation de ce processus. De plus, il y a aussi des employés inexpérimentés dans l'équipe qui ne sont pas entièrement familiarisés avec les règles de développement internes et ont tendance à faire plus d'erreurs. Pour contrôler la qualité du code, il a été décidé d'implémenter un analyseur statique. Étant donné que SonarQube a déjà été utilisé dans certains systèmes NSD, il n'a pas fallu longtemps pour choisir. Auparavant, des collègues d'autres divisions l'utilisaient pour analyser le code des microservices dans le système Alameda (système comptable de dépôt et de compensation propre à NSD), dans le CFT (système d'information pour la comptabilité, la balance, la préparation des rapports obligatoires et internes), dans d'autres systèmes. Pour l'expérimentation, nous avons décidé de commencer par la version gratuite de SonarQube. Passons donc à notre cas.
Processus de mise en œuvre
Nous avons:
- assemblage automatique du système dans TeamCity ;
- mettre en place le processus d'upload de code via MergeRequest d'une branche feature vers la branche master dans GitLab (processus de développement selon GitHub Flow) ;
- SonarQube configuré pour analyser le code du système DPO dans les délais.
Notre but: implémenter l'analyse automatique de code dans les processus CI/CD d'AVE.
Besoin de personnaliser: le processus de vérification automatique du code par un analyseur statique à chaque MergeRequest vers la branche principale.
Ceux. l'image cible est la suivante : dès que le développeur télécharge des modifications dans la branche de fonctionnalités, une vérification automatique des nouvelles erreurs dans le code démarre. S'il n'y a pas d'erreurs, les modifications peuvent être acceptées, sinon les erreurs devront être corrigées. Déjà au stade initial, 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 telle manière qu'il fonctionne 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 une chose que nous lisons dans les entrailles d'Internet. Au départ, nous avons utilisé une approche différente, plus complexe et, à certains égards, pas tout à fait correcte. Tout d'abord, nous avons exécuté l'analyse à travers SonarQube deux fois : nous avons analysé la branche de fonctionnalité et la branche où nous allions fusionner la branche de fonctionnalité, puis nous avons comparé le nombre d'erreurs. Cette méthode n'était pas stable et ne donnait pas toujours le bon résultat. Et puis nous avons appris qu'au lieu d'exécuter SonarQube deux fois, vous pouvez définir une limite sur le nombre d'erreurs commises (QualityGate) et analyser uniquement la branche que vous téléchargez et comparez.
Pour l'instant, nous utilisons encore une vérification de code plutôt primitive. Il est à noter que SonarQube n'est pas compatible avec certains langages de programmation, dont Delphi. Pour le moment, pour notre système, nous analysons uniquement le code PLSql.
Cela fonctionne comme ceci:
- Nous analysons uniquement le code PL/SQL pour notre projet.
- QualityGate est configuré dans SonarQube pour que le nombre d'erreurs n'augmente pas avec le commit.
- Le nombre d'erreurs lors de la première exécution était de 229. S'il y a plus d'erreurs lors de la validation, la fusion n'est pas autorisée.
- De plus, sous réserve de la correction des erreurs, il sera possible de reconfigurer QualityGate.
- Vous pouvez également ajouter de nouveaux éléments à analyser, par exemple, la couverture du code avec des tests, etc.
Programme de travail:
Dans les commentaires du script, vous pouvez voir que le nombre d'erreurs dans la branche de fonctionnalité n'a pas augmenté. Donc tout va bien.
Le bouton Fusionner devient disponible.
Dans les commentaires du script, vous pouvez voir que le nombre d'erreurs dans la branche de fonctionnalité est devenu plus que autorisé. Donc tout est MAUVAIS.
Le bouton Fusionner est rouge. Pour le moment, il n'y a aucune interdiction de télécharger des modifications de code erroné, mais cela est fait à la discrétion du développeur responsable. À l'avenir, vous pourrez empêcher que de tels commits soient effectués sur la branche principale.
Gestion autonome des bogues
Ensuite, vous devez vérifier toutes les erreurs détectées par le système, car SonarQube analyse selon ses normes strictes. Ce qu'il considère comme une erreur n'en est peut-être pas une dans notre code. Par conséquent, vous devez vérifier et noter s'il s'agit vraiment d'une erreur ou s'il n'est pas nécessaire de modifier nos conditions. Ainsi, nous réduisons le nombre d'erreurs. Au fil du temps, le système apprendra à comprendre ces nuances.
À quoi sommes-nous arrivés
Notre objectif était de comprendre s'il est opportun dans notre cas de transférer la vérification du code vers l'automatisation. Et le résultat a été à la hauteur des attentes. SonarQube nous permet de travailler avec les langages dont nous avons besoin, effectue des analyses assez compétentes et a le potentiel d'apprendre des astuces des développeurs. De manière générale, nous sommes satisfaits de notre première expérience avec SonarQube et prévoyons de nous développer davantage dans cette direction. Nous espérons qu'à l'avenir, nous pourrons économiser plus de temps et d'efforts sur la révision du code et l'améliorer en éliminant le facteur humain. Peut-être qu'au cours du processus, nous découvrirons les lacunes de la plate-forme ou, au contraire, nous nous assurerons une fois de plus qu'il s'agit d'une chose cool avec un grand potentiel.
Dans cet article de synthèse, nous avons parlé de notre connaissance de l'analyseur statique SonarQube. Si vous avez des questions, veuillez écrire dans les commentaires. Si ce sujet vous intéresse, dans la nouvelle publication, nous décrirons plus en détail comment tout configurer correctement et écrire du code pour effectuer une telle vérification.
Auteur du texte:
Source: habr.com