Stratégies pratiques de test des microservices

Lors de la migration d'une architecture monolithique vers une architecture microservices, nous avons apporté des modifications substantielles à l'outillage et aux processus afin de prendre en charge plusieurs versions de logiciels de haute qualité par jour.

Le problème

Chez FloQast, nous avons commencé avec une architecture logicielle monolithique, mais au fur et à mesure que le nombre de produits et d'équipes scrum augmentait, nous avons commencé à passer à une architecture basée sur les microservices. Au début, pendant cette transition, nous avons continué à utiliser l'environnement d'assurance qualité unique et partagé (un vestige de la période de déploiement monolithique) pour les tests de bout en bout avant le déploiement en production. Au fur et à mesure que le nombre de microservices augmentait, nous avons commencé à rencontrer des goulets d'étranglement dans notre environnement d'assurance qualité - les bogues trouvés dans l'environnement d'assurance qualité entraînaient un retard de quelques heures en raison du cycle de correction-déploiement-vérification et retardaient les versions à venir pour les mêmes services ou des services dépendants. Cela s'explique principalement par le fait que c'était la première fois que les services étaient déployés dans un environnement de type production contenant d'autres services et exposés à des données de test plus réalistes.

La solution

Pour résoudre ce problème, nous avons réexaminé l'ensemble du processus, de l'infrastructure et de l'outillage de mise en production et nous avons apporté quelques améliorations, illustrées dans l'image ci-dessus et décrites ci-dessous :

Introduction d'environnements de développement locaux

Comme la plupart de nos microservices sont Dockerisés et s'exécutent dans un conteneur Docker, notre équipe de développement a utilisé Docker Compose pour construire des environnements de développement locaux contenant une majorité de nos microservices. Pour les services utilisant les services AWS (Lambda, etc.), nous avons utilisé des outils de test locaux fournis par AWS, tels que SAM local. Cela a permis aux développeurs de tester leurs changements de code localement de manière intégrée avant de créer des demandes de téléchargement.

Création d'environnements de test AWS par l'équipe Scrum

Chez FloQast, nous sommes tous sur AWS et l'équipe DevOps de FloQast avait déjà commencé à terraformer toute l'infrastructure AWS en tant que code. Pour les équipes qui rencontraient des goulets d'étranglement dans l'environnement QA partagé, DevOps a créé des environnements de type production à l'aide de Terraform. Pour maîtriser les coûts, nous avons construit ces environnements avec seulement le sous-ensemble de services nécessaires à chaque équipe et nous avons utilisé des tailles d'instance inférieures à celles de la production. Ensuite, nous avons mis en place des tâches planifiées par Jenkins pour maintenir les services mis à jour quotidiennement avec la branche déployée en production.

Configurer les tests UI/API pour qu'ils s'exécutent dans plusieurs environnements

Après avoir mis en place ces environnements de test par équipe, nous avons modifié nos configurations de test UI/API afin qu'elles puissent être exécutées avec succès dans des environnements multi-équipes. Cela impliquait de trouver un moyen fiable d'alimenter et de maintenir les données de test dans des environnements multiples.

Optimiser l'étape de test de chaque microservice dans le pipeline CI/CD

Les microservices sont censés pouvoir être déployés et testés indépendamment. Nous avons donc examiné les fonctionnalités de chaque microservice et sélectionné des tests de notre suite principale d'automatisation des tests UI/API qui s'appliquent au microservice spécifique testé. Cela a permis de réduire davantage le cycle de retour d'information pour la détection des bogues dans les environnements de test.

Au cours des deux dernières années, alors que nous mettions ces changements en place, nous avons observé une baisse significative des goulets d'étranglement dans l'environnement d'assurance qualité partagé et nous sommes progressivement passés d'un cycle de publication hebdomadaire avant mai 2018 à un déploiement de code plus de cinq fois par jour en mars 2020 (voir l'image ci-dessous).

Conclusion

Pour tirer toute la valeur commerciale d'une migration vers les microservices, examinez attentivement toutes les étapes de votre processus de mise à disposition de logiciels. Parmi les domaines à explorer, citons l'introduction d'environnements de développement locaux, la création d'environnements de test par équipe, basés sur cloud, et l'ajustement de l'automatisation des tests UI/API. Ces changements prennent du temps, mais une fois qu'ils sont effectués, vous commencez à récolter les fruits de plusieurs versions de haute qualité par jour !

Saurabh Deshpande

Saurabh est responsable de l'ingénierie de la qualité chez Floqast. En dehors du travail, il aime jouer au tennis de table et faire la lecture à son fils.