Intégration continue : Zuul, une occasion en or pour LeBonCoin
Le site de petites annonces a choisi le projet de fondation OpenStack Zuul, pour piloter les tests à l’échelle et gérer ses processus d’intégration continue. LeBonCoin a troqué son infrastructure Jenkins.
Avec plus de 150 développeurs et plus de 5 000 révisions de code, LeBonCoin n’a certes pas l’ampleur du projet OpenStack et de ses plus de 10 000 modifications mergées par mois et ses 2 000 committers. Mais le site français, spécialisé dans les petites annonces, affiche une progression telle de son trafic qu’il nécessite lui-aussi d’avoir recours à des techniques de développements et de tests de ses fonctionnalités à grande échelle. LeBonCoin, avec plus de 28 millions de pages vues uniques par mois et plus de 27 millions de petites annonces (« classified ads ») correspond au 5e site le plus visité dans l’Hexagone.
La comparaison avec OpenStack s’arrête-t-elle là ? Non, car LeBonCoin, pour soutenir l’évolution de ses processus de développement et son architecture globale, emprunte également à la fondation OpenStack l’un de ses projets cœur qui sous-tend les phases de test du projet d’infrastructure cloud open source : Zuul.
Zuul est l’un des 4 projets qui ont pris leur indépendance aux côtés d’OpenStack au sein de la fondation – avec les Kata Containers, AirShip et StarlingX. Zuul est issu des développements même d’OpenStack, alors que la fondation s’est retrouvée confronté à des goulets d’étranglements dans ses processus d’intégration continue et des tests de la pile OpenStack.
Concrètement, Zuul correspond en fait à un projet de « gating » dont l’ambition est de réaliser des séries de tests en parallèle, tout en s’appuyant sur plusieurs repositories de codes. Les modifications apportées au code ne sont mergées que si les batteries de tests – celles-ci peuvent être personnalisées - ont réussi. Cette méthode a plusieurs avantages : en parallélisant les jobs et en les automatisant, les tests se retrouvent accélérés et ne rebutent plus les développeurs. Ils ne les écartent plus de leur quotidien. L’approche multi-repositories permet quant à elle d’inclure des projets tiers et leurs dépendances pour des tests holistiques et sûrs.
Cette méthode appliquée par la fondation a séduit LeBonCoin. Le site ne s’est doté qu’en 2015 d’une équipe dédiée à l’intégration continue (CI). Cette infrastructure de CI originale se reposait sur un master Jenkins et Gerrit pour les reviews de code. Dès 2016, l’outillage de cette infrastructure a été étendu « afin de faciliter la collaboration avec les autres membres des équipes », note Guillaume Chenuet, ingénieur DevOps chez LeBonCoin. Sphinx pour la documentation et Reno pour les notes de releases ont notamment été mis en place. GitHub s’est mis à côtoyer Gerrit.
Il faut ajouter que le site a également dû revoir l’architecture globale du site pour passer à une approche microservices. Un découpage différent et plus granulaire qui imposait également une refonte de l’infrastructure de test pour faciliter la vie des développeurs…et pour intégrer justement cette dimension de test automatisé à l’échelle.
Une réorganisation qui embouteille
Comme toute entreprise à forte croissance, LeBonCoin a également conduit une ré-organisation de ses équipes. « Nous avions une équipe back-end et une équipe front-end, ainsi que différentes équipes mobiles. Cela fonctionnait, mais nous ne disposions pas de la vélocité nécessaire pour de nouveaux développements. Nous sommes donc passés à une organisation qui repose sur des équipes dédiées aux fonctions (NDLR, on parle de « Feature team »), comme peut le faire Spotify », explique Guillaume Chenuet.
Il n’est [...] plus nécessaire d’attendre chaque équipe. Les cycles de développement sont beaucoup plus rapides.
Guillaume Chenuetingénieur DevOps, LeBonCoin
Il s’agit d’équipes pluri-disciplinaires, composées de personnes de chaque entité, tant back-end que front-end, qui travaillent ensemble sur un sujet précis. « Il n’est donc plus nécessaire d’attendre chaque équipe. Et les cycles de développement sont beaucoup plus rapides, on gagne en vélocité », ajoute le responsable.
Cette réorganisation en interne a certes contribué à améliorer les cycles de développement, mais aussi à créer un goulet d’étranglement dans l’outillage, qui ne parvenait justement plus à tenir ces nouvelles cadences. Après avoir ajouté plusieurs masters Jenkins pour compenser, des limites notamment en matière de « gating » persistent. Justement.
LeBonCoin est donc passé à Zuul pour être capable d’absorber ces processus à l’échelle, et ses développements en parallèle. « Nous disposions certes d’une forme d’agilité. Mais Zuul, dans sa version 2, s’est présenté lorsque nous avions atteint la limite de nos outils en place », appuie de son côté Benoit Bayszczak, également ingénieur DevOps dans l’entreprise.
Plusieurs jobs de tests Zuul sont gérés en parallèle (build, intégration avec des tests unitaires, et un sur la qualité) à partir de Gerrit. Un job « Post-Merge » Zuul est également mis en place, une fois le code mergé dans Gerrit.
« Les microservices correspondent à des temps de test très courts, précise à son tour, Sonia Ouchtar, ingénieure DevOps au bon coin. Cela nous permet de donner des feedbacks plus courts auprès des développeurs ». Par exemple, avec l’infrastructure monolithique, les temps de build était de 45mn pour chaque modification. Mais « avec Zuul et les 6 masters Jenkins, les tests sont réalisés en 5 minutes », lance-t-elle.
Les tests ont également été réécrits afin qu’ils soient très courts, affirment les membres de l’équipe, de sorte qu’il n’existe plus « la tentation de bypasser les tests. Les tests ne sont plus les ennemis des développeurs ».
« Le passage de 1 Jenkins à 6 Jenkins avec Zuul v2 a nécessité 2 mois de travail à 2 personnes », précise-t-il. Un temps plutôt court. Cela comprend également la réécriture des scripts pour être compatibles avec Zuul. Aucune interruption de service n’a été notée.
Mais avec la migration vers Zuul v3 initiée en 2018, le chantier est d’une plus grande ampleur. Car « une nouvelle stack complète est mise en place, en plus des deux clusters OpenStack », résume encore Guillaume Chenuet. « Tout disparait, sauf Gerrit. » Même Jenkins : dans cette migration, les jobs de Jenkins deviennent également des playbooks Ansible. Mais l’OpenStack Foundation ayant déjà essuyé les plâtres d’une telle migration, les travaux ont pu être raccourcis. « On essaie de ne pas trop dériver et nous restons très proches de la fondation. » LeBonCoin commence d’ailleurs à contribuer à Zuul.
Une infrastructure flexible bâtie sur OpenStack
LeBonCoin s’adosse à un déploiement classique d’Openstack, qui ne sert qu’aux processus d’intégration continue. La société a mis en place deux clusters composés de 3 contrôleurs, 3 composants stockage et 5 composants compute, le tout en redondance sur 2 datacenters. Quelques 100 VM tournent sur ces 2 clusters. Mais, avec la montée en puissance du site, des composants compute ainsi que d’autres composants OpenStack pourraient être ajoutés, rapporte encore l’expert. Ces composants pourraient par exemple permettre d’exposer des services aux développeurs, car pour l’heure ces clusters sont réservés aux équipes d’intégration continue.
« C’est aussi un bon moyen de promouvoir OpenStack en interne. Nous sommes un bon client AWS, et cela permet de montrer que nous pouvons le faire chez nous », ajoute-t-il. L’infrastructure est hébergée sur site, mais les débordements (notamment pour les PoC) sont gérés sur AWS.
