Le Cloud au service de la qualité applicative

Depuis la rentrée, DARVA s’appuie sur de nouvelles solutions du Cloud (G. Cloud, kubernetes, Slack…) pour améliorer la Qualité Applicative des développements de sa plateforme Sinapps. A travers cette mise en œuvre, elle démontre sa volonté d’industrialiser et d’améliorer la qualité de ses processus.

Explications par Anthony CHARLES, Responsable de l’Architecture

Sa fonction : Garantir la cohérence des choix d’Architecture au niveau entreprise en lien avec les différentes usines digitales de DARVA et la Direction de l’Infrastructure.

Anthony, pourquoi DARVA a-t-elle fait appel au Cloud pour améliorer la Qualité Applicative ?

DARVA construit des plateformes collaboratives, le plus souvent multitenants, destinées à la gestion des sinistres en Auto et Habitation.  Chaque plateforme fait appel à des composants applicatifs de différentes natures (internes/externes) ainsi qu’à des composants d’infrastructure (bases de données, stockage objet,…).

En pleine transformation digitale, nous avons perçu la nécessité d’industrialiser les processus permettant de garantir une qualité applicative optimale pour la réalisation de nos  plateformes. Déjà engagés dans une démarche Docker, l’implémentation technique à l’aide de Kubernetes est rapidement devenue une évidence mais nous ne disposions pas de cet outillage. C’est pourquoi la mise en œuvre d’un Cloud public nous a permis de démarrer cette implémentation, en nous laissant la possibilité à moyen terme d’internaliser facilement cette solution ou bien de changer de fournisseur Cloud.

Comment la Qualité Applicative intervient-elle dans le cycle de vie des solutions développées à DARVA ?

La qualité applicative se pilote principalement sous trois angles :

  • La qualité du code développé encadrée par de nombreux tests unitaires et l’analyse du code via un outil spécialisé.
  • La vérification fonctionnelle découlant d’un correctif ou d’une évolution spécifique qui va modifier le code de l’application. Cette modification du code impacte le cycle de vie applicatif à l’aide d’une “Pull Request”  (on utilise couramment le terme de PR) via l’outil de gestion des sources Git.  Un collaborateur peut alors vérifier le bon comportement de la PR.
  • La non régression globale de la solution, enrichie avec de nombreuses PR, est pilotée via des scénarios automatisés API et des tests de performance. Cette démarche permet de s’assurer que les différentes PR validées ne vont pas engendrer de régression tant fonctionnelle qu’en termes de performance sur la solution globale.

Nous avons implémenté deux processus :

  • Un processus PR permettant de mettre à disposition, pour une PR ciblée, un écosystème applicatif complet pour tester rapidement le développement réalisé.
  • Un processus de tests de non régression permettant de construire toutes les nuits un écosystème applicatif complet pour valider automatiquement qu’il n’y a pas de régressions sur la solution globale.

Sur quelles technos vous appuyez-vous ?

Notre démarche consiste dans un premier temps à construire l’ensemble des composants applicatifs de la solution sous forme de containers Docker (composants développés en Scala, Java) et à identifier des containers du marché pour les composants techniques et transverses (Etcd, MongoDB, Postgresql, SQLserver, Stockage S3,…).

Notre outillage qualité est basé sur Postman (Outil de tests API), Neoload (Tests de charge) et SonarQube (Contrôle de la qualité du code). Nous pilotons les workflows de construction, de déploiement et de tests qualité à l’aide de Jenkins.

Concernant le déploiement, il est réalisé sur un cluster Kubernetes, mis en œuvre sur GCloud à l’aide de plusieurs namespace (ce qui nous permet un cloisonnement sécurisé des différentes instances d’environnement).  Nous avons choisi GCloud car la console d’administration est relativement simple et l’implémentation de Kubernetes est reconnue comme une des meilleures du marché.

Enfin,  nous avons utilisé la plateforme collaborative Slack pour communiquer les URL d’accès provisionnées dynamiquement lors des déploiements, ainsi que les URL d’accès aux rapports de déploiement et de test.

Dans quel cadre avez-vous mis en place ces processus ? Sur quel projet ont-ils été expérimentés ?

Il est fréquent de débuter ce type de mise en œuvre par des applications simples… mais notre besoin immédiat concernait SINAPPS, une des applications les plus riches de DARVA. SINAPPS est la plateforme collaborative de DARVA qui accueille différents métiers dans le domaine de l’habitation. Une importante équipe projet est mobilisée sur cette plateforme en pleine conquête de marché avec des évolutions fonctionnelles régulières.

Cette plateforme est constituée de 12 containers (7 liés à l’application, les autres étant des composants techniques…). 5 autres containers transverses sont utilisés pour l’outillage de test de charge et le contrôle qualité du code applicatif. Les deux processus évoqués précédemment sont implémentés.

  • Processus Pull Request

 L’élasticité de Kubernetes permet d’absorber facilement un pic de validation induisant de multiples instances de l’environnement déployées en parallèle

  • Processus de tests de non régression

En complément du processus précédent, il est indispensable de vérifier toutes les nuits que la plateforme est stable fonctionnellement et techniquement dans son ensemble.

Quels sont les retours au sein de vos équipes ?

Il est un peu tôt pour se prononcer sur les gains réels mais les premières démonstrations prouvent une réelle attente sur ce sujet.  La mise au point est réalisée avec le TechLead de l’équipe SINAPPS qui exprime ses besoins pour  satisfaire l’ensemble de l’équipe projet.

Si à première vue, le montage est relativement simple il y a néanmoins des sujets techniques à traiter afin de proposer une expérience utilisateur satisfaisante (cf. industrialisation des jeux d’API lancés, reformatage des journaux Postman  pour faciliter l’analyse, formatage des messages Slack…).

Quand et comment pensez-vous l’intégrer dans vos processus ? 

L’ensemble du dispositif est en cours de finalisation avec pour objectif de l’exposer rapidement à l’équipe SINAPPS. Par la suite, la mise en œuvre réalisée pourra facilement être généralisée à d’autres solutions éditées et opérées par DARVA. 

Quels sont les bénéfices pour vos clients ?

Je suis convaincu que l’approche industrielle mise en œuvre permettra des gains de productivité significatifs sur le processus de QA tout en limitant les régressions liées à une application qui évolue rapidement.

Quelles évolutions envisagez-vous ?

Une première maquette est opérationnelle pour compléter l’outillage de non régression avec des tests extranet basés sur Cypress. Nous avons également débuté l’implémentation d’un Chatbot, couplé à Slack, pour donner plus de souplesse sur le déploiement des environnements dans le cadre du processus PR. Enfin, nous avons engagé la mise en œuvre de Kubernetes au sein de notre SI, ce qui permettra le moment venu, de vérifier la réversibilité du montage débuté avec GCloud.