Fitch offre une couverture et une qualité de code élevées pour les applications de microservices

Regardez un aperçu de la présentation de Fitch lors du récent Sommet automatisé sur les tests et la qualité des logiciels. Découvrez comment ils ont géré les dépendances pour plus de 200 microservices et augmenté la couverture du code grâce aux tests unitaires.

PRÉSENTATION COMPLÈTE DISPONIBLE ICI >>

Les défis

Fitch avait trois problèmes principaux à résoudre :

• Temps d'arrêt imprévu
• Manque de retours pour les développeurs
• Cycles de sortie rigides de deux semaines

Temps d'arrêt imprévu

En 2019, Fitch a eu 18 incidents qui ont causé la panne de son site Web en raison de pannes dans l'environnement de production. Ces pannes imprévues étaient liées soit à leurs propres API, soit à d'autres produits qu'ils hébergent. Dix-huit incidents en moyenne à plus d'une fois par mois. C'est une mauvaise nouvelle pour les accords de niveau de service (SLA) et leurs clients.

Manque de commentaires pour les développeurs

L'équipe de développement logiciel de Fitch Solutions est fluide. Les développeurs passent d'un projet à l'autre, il est donc courant qu'ils travaillent et deviennent responsables de microservices qui leur sont inconnus. L'ajout de fonctionnalités à du code inconnu était difficile car il y avait peu de tests pour offrir des résultats et aider les développeurs à comprendre le comportement attendu. En outre, les experts en la matière (PME) n'étaient souvent pas disponibles pour être consultés.

Tous ces facteurs combinés (les développeurs changent souvent d'équipe, n'ont pas accès aux PME et ont une faible couverture de test d'environ 20 %) ont conduit à un manque de retour d'information. Les informations manquantes ont entravé la capacité de l'équipe à maintenir le fonctionnement des services et à ajouter de nouvelles fonctionnalités. C'est pourquoi Fitch a pris des mesures pour atteindre un niveau plus élevé de couverture des tests.

Cycles de publication rigides de deux semaines

Des cycles de publication de deux semaines sont le processus de développement standard chez Fitch. Les développeurs n'ont pas été en mesure de publier selon leur propre calendrier. Ainsi, si le développement d'une nouvelle fonctionnalité était terminé avant la fin du cycle de déploiement, il fallait attendre la fin du sprint pour passer au contrôle qualité. Idéalement, ils devaient être capables de développer et de déployer une fonctionnalité chaque fois qu'elle était implémentée et testée. Cela leur permettrait de publier plus souvent de nouvelles fonctionnalités et d'accélérer leur mise sur le marché.

L'approche

Fitch Solutions a pris en compte ces trois défis majeurs et a recherché un dénominateur commun entre les trois. Il est devenu évident que tous les trois étaient liés au manque de tests entraînant une mauvaise couverture du code. Ils ont décidé d'augmenter la couverture du code pour s'assurer qu'ils testaient pleinement leurs microservices et aider leurs développeurs à fournir un meilleur code à un rythme plus rapide.

Une bonne couverture de code sur un microservice signifie que la plupart, sinon la totalité, des chemins à travers le code sont exécutés. La création d'une suite de tests pour chaque microservice qui couvre toutes les différentes fonctions signifie que le code non testé n'est pas exposé aux clients. Pour tout changement futur, les tests de régression automatisés donnent aux développeurs un retour instantané pour savoir si quelque chose dans le code s'est cassé.

Cette approche finit par réduire les pannes. Il est plus efficace et efficient de tester les fonctionnalités actuelles et nouvelles avant de passer à la production. Cette approche a aidé Fitch Solutions à réduire la dépendance vis-à-vis de son groupe d'assurance qualité pour organiser et tester de nouvelles fonctionnalités et découpler le développement de fonctionnalités du cycle de publication de deux semaines.

Une approche à deux volets pour augmenter la couverture du code

Le plan proposé par Fitch Solutions était d'atteindre une couverture de test unitaire de 90 % (en particulier une couverture de ligne). C'était une grosse tâche car ils ont plus de 200 microservices ! L'équipe était à la hauteur du défi et a utilisé une approche à deux volets pour le relever.

Créer de nombreux nouveaux tests

Le premier volet de l'approche consistait à augmenter rétroactivement la couverture de test de tout le code existant. Pour atteindre l'objectif de couverture de code de 90 %, ils ont dû créer de nombreux nouveaux tests. Ils ont réuni une équipe dédiée pour s'attaquer à ce problème. L'équipe était chargée d'écrire des tests unitaires exclusivement pour développer la couverture de code et tester entièrement les microservices existants de Fitch Solutions.

Suivez les directives de test unitaire

Le deuxième volet de cette approche était de s'assurer que les développeurs qui écrivent de nouvelles fonctionnalités suivent les directives de test unitaire et atteignent les objectifs de couverture de code au fur et à mesure que le nouveau code est écrit. Ces directives ont été appliquées dans toute l'organisation pour que tous les développeurs les mettent en pratique. L'équipe a introduit des portes de qualité pour assurer la qualité du code fusionné dans la branche de production principale.

Adopter un outil de test Java intégré pour atteindre les objectifs

Pour atteindre leurs objectifs de test, de couverture et de qualité, Fitch Solutions a adopté Jtest Parasoft. Ils ont trouvé particulièrement utile d'utiliser à la fois les capacités de couverture de code et les assistant de test unitaire dans Parasoft Jtest. Si les développeurs écrivaient de nouvelles fonctionnalités ou testaient à nouveau les services existants, ils mesuraient d'abord la couverture du code pour évaluer l'étendue des tests existants. Ils ont utilisé les rapports de couverture de code de Jtest à tous les niveaux pour découvrir où leurs tests manquaient, y compris pour enquêter sur la couverture manquante au niveau du fichier et de la ligne de code.

L'assistant de test unitaire a aidé Fitch Solutions à combler le vide des tests unitaires. Les développeurs ont créé de nouveaux tests unitaires en cliquant sur un bouton tout en survolant une méthode dans le code. L'assistant de test unitaire crée un fichier de test, un faisceau et des stubs/mocks selon les besoins. Les développeurs ajoutent simplement des assertions pour vérifier le comportement et ajuster les simulations, et un nouveau test unitaire est prêt.

Toute l'équipe a accéléré la création et l'exécution des tests à l'aide de Parasoft Jtest. Cela a été particulièrement utile pour leurs développeurs juniors qui avaient besoin de conseils sur la création de tests unitaires.

Avantages de la solution

Fitch Solutions est toujours en train d'améliorer ses tests de logiciels. Ils profitent déjà des avantages de leur solution Parasoft.

• Un moyen fiable de mesurer et d'améliorer la couverture du code.
• Création et maintenance de tests unitaires accélérés.
• Temps d'arrêt réduit.
• Augmentation de la productivité des développeurs.

Les Résultats

Au troisième trimestre de 3, Fitch Solutions a amélioré ses tests de 2020 % des microservices pour atteindre son objectif de 10 % de couverture de code. Bien qu'ils soient toujours en train d'atteindre leurs objectifs de couverture, ils ont passé 90 jours sans aucun temps d'arrêt dans leur système de production. C'est leur plus longue séquence depuis l'adoption de leur nouvelle approche de tests unitaires. Vince Recupito, ingénieur logiciel senior chez Fitch Solutions, a déclaré : « Ce qui est très excitant, c'est que nous avons passé 100 jours sans aucun temps d'arrêt dans notre système de production. Quelque chose qui se passait plus que tous les mois.

Fitch Solutions s'est engagé avec une société tierce spécialisée dans la mesure de la productivité des développeurs. L'analyse approfondie utilise un accès direct aux référentiels de code pour mesurer l'historique des commits et trouver des tendances et des métriques en fonction des activités des développeurs.

Le graphique ci-dessus a été créé à partir des données de productivité collectées montrant le temps moyen mensuel que les développeurs passent à écrire du code par jour.

Les données montrent que l'équipe de Fitch passait environ deux heures par jour à taper sur un clavier, à écrire du code. La baisse de janvier devrait être due aux vacances. La partie intéressante est le début de leur nouvel effort de test en juillet.

À ce stade, l'équipe revenait sur ses anciens microservices, évaluait et augmentait la couverture de code. C'est aussi le moment où l'équipe a insisté pour que toutes les nouvelles fonctionnalités soient testées correctement.

Après cette baisse initiale, l'équipe était de retour dans le développement de code à un taux de 12% supérieur à celui de la même période en 2019. C'était un bon signe car les développeurs passaient plus de temps à coder et moins de temps en réunion. Cependant, la cause première de cette augmentation de la productivité était la diminution significative des temps d'arrêt du système de production.

« L'une des conclusions que nous tirons est que nos développeurs passent moins de temps à résoudre les problèmes de production et plus de temps à écrire du code. En plus de cela, alors que les développeurs écrivent plus de tests, j'espère qu'ils trouveront des bogues plus tôt avant de passer au contrôle qualité.

—Vince Recupito, ingénieur logiciel senior chez Fitch Solutions

Fitch Solutions a non seulement constaté une réduction des temps d'arrêt du système de production, mais également une réduction du nombre de développeurs « combattant l'incendie » pour résoudre les problèmes de production. De plus, le nouveau régime de test a eu peu d'impact sur la productivité de leurs développeurs avec une augmentation observée de la productivité de 12%.

En plus de ces gains, les développeurs de Fitch Solutions écrivent plus de tests et trouvent des bogues plus tôt, avant qu'ils ne passent au contrôle qualité. Trouver des bogues plus tôt signifie également moins d'allers-retours avec l'AQ et moins de temps dans le processus d'AQ dans son ensemble.