DPE University
À propos de Criteo
Criteo (NASDAQ: CRTO) est un fournisseur de publicité en ligne coté en bourse évalué à plus de 2 milliards de dollars et dont le siège est à Paris. Sa plateforme Commerce Media, leader du secteur, connecte des milliers de spécialistes du marketing et de propriétaires de médias pour offrir aux consommateurs des expériences plus riches, de la découverte du produit à l’achat.
Nous avons parlé avec Emmanuel Guérin (Staff DevOps Engineer) et Loïc Teikietini-Vaysse (Staff DevOps Engineer) chez Criteo pour comprendre comment Develocity change la façon dont leurs équipes de développement analysent, observent et signalent rapidement les problèmes de build.
Criteo compte plus de 3 500 collaborateurs sur 5 continents
Décrivez le rôle de votre équipe et vos responsabilités envers l’organisation de développement Criteo au sens large.
Notre équipe est responsable de gérer l’intégration continue pour la majorité de nos applications développées en interne. Notre objectif principal est de standardiser le versioning de nos modules et les dépendances entre les modules de différents dépôts Git.
En ce sens, nous sommes un des moteurs de la productivité et de l’expérience des développeurs chez Criteo et nous visons à fournir une expérience utilisateur simple et unifiée dans les différents environnements et technologies supportées. Pour ce faire, nous suivons les métriques DPE telles que le délai de résolution des échecs de build et de test, ainsi que la recherche de root cause pour les problèmes complexes de gestion des dépendances.
Décrivez votre environnement global de développement, de build et de test afin que nous puissions comprendre votre déploiement Develocity dans son contexte.
Les centaines d’ingénieurs logiciels de Criteo adoptent une approche polyglotte de la programmation, utilisant Java ainsi que .NET, Python, Go et d’autres langages. L’équipe globale travaille avec environ 1000 dépôts Git et build 6000 projets, environ 20 fois par jour.
Cela représente environ 13 000 builds quotidiens de CI (ce qui équivaut à 60 jours de builds chaque jour) et 2 500 builds quotidiens des développeurs sur leur poste de dev.
Pour nos builds Java en intégration continue, nous sommes passés d’Apache Maven à Gradle il y a quelques années car nous recherchons un outil qui pourrait nous aider à:
- Assurer le monitoring de nos builds
- Comparer rapidement les versions
- Résoudre des problèmes complexes de résolution de dépendances
Depuis lors, les environnements de développement locaux et CI utilisent la combinaison de la ligne de commande Gradle et de Develocity™ comme interface utilisateur principale pour nos développeurs. Develocity Build Scan ® a été notre principal outil de reporting : plus besoin de nous battre avec des centaines de pages de journaux Jenkins et des rapports de tests surchargés qui nous empêchaient de trouver rapidement la root cause d’une panne.
Develocity nous fournit les métriques dont nous avons besoin avec très peu d’effort et nous aide à comprendre l’impact de notre travail sur l’ensemble du système.
Quels défis ou problèmes de productivité des développeurs avez-vous résolus avec Develocity ?
Nous devons prendre en charge plusieurs piles technologiques et il est important que nous maintenons le même niveau de service pour le cycle de vie, les performances, les rapports, etc. de chaque stack technologique que nous supportons.
Travailler dans ce type d’environnement hétérogène, où les builds CI et locaux sont exécutés en permanence, est un défi, en particulier lorsqu’il s’agit de détecter des problèmes spécifiques à un environnement particulier.
Par exemple, nous utilisons le tagging pour suivre les erreurs aléatoires lors du téléchargement sur nos différents dépôts. Récemment, nous avons remarqué un manque de stabilité dans ce processus. En utilisant les dashboards de Develocity Failure Analytics pour explorer ces tags, nous avons réussi à identifier qu’un seul de nos dépôts était responsable de la plupart de nos instabilités. Cela aurait été impossible sans Develocity.
Nous avons également découvert l’immense avantage de publier chaque build local sous forme de Build Scan afin de mieux accompagner nos utilisateurs. Cela nous aide à surveiller l’utilisation de différentes fonctionnalités localement, et résoudre rapidement les différents problèmes qu’ils rencontrent.
Par exemple, l’investigation des erreurs de build prenait auparavant 5 à 10 minutes, et maintenant ce n’est plus qu’une question de secondes avec les données fournies par les Build Scans. Cela aide également à résoudre les problèmes complexes impliquant des dépendances transitives et d’autres défis de gestion des dépendances.
Ainsi, la première chose que nos utilisateurs entendent généralement de notre part est « Envoyez-nous votre (URL) Build Scan » s’ils n’ont pas déjà appris à la fournir.
Décrire comment utiliser Develocity Build Scan et Failure Analytics
“La résolution de dépendances est vraiment claire pour nous avec Build Scan. Nous sommes mieux équipés pour gérer ces problèmes car nous n’avons pas besoin de repartir de zéro : auparavant, cela nous prenait jusqu’à 30 minutes pour comparer les dépendances, mais maintenant nous pouvons simplement comparer le dernier build avec le dernier build réussi et voir immédiatement quelles dépendances ont changé.”
Loïc Teikiteetini-Vaysse – Staff DevOps Engineer
Build Scan
Nous utilisons Develocity Build Scan comme principal système de reporting. Les utilisateurs se voient directement présenter les URL de leur Build Scan dans leur rapport d’exécution (au lieu des URL de Jenkins par exemple), ce qui leur permet de trouver plus facilement la source d’erreurs. Nous avons également implémenté un plugin Gradle qui permet aux développeurs de déclarer les fichiers générés sous forme de rapports supplémentaires qui seront publiés dans Build Scan pour plus d’informations sur des sujets spécifiques.
Un Build Scan est le point d’entrée privilégié pour lire et comprendre n’importe quelle build CI. Dans l’image ci-dessus, nous pouvons voir (1) une erreur de compilation, (2) la validation donnée par la CI ici en échec, (3) un résumé des échecs est affiché dans le message de retour, (4) des raccourcis permettent d’accéder rapidement au rapport de build et notamment aux rapports de test dans Build Scan.
La page principale d’un Build Scan donne à nos utilisateurs un aperçu concis de la façon dont le build s’est déroulé. Dans l’image ci-dessus, nous voyons (1) où le build a échoué et (2) un échec est mis en avant avec un petit aperçu de la cause. De là, nous pouvons accéder à la console des tâches ayant échouées.
L’analyse (1) de la console de log filtrée par tâche dans l’image ci-dessus permet à nos utilisateurs une meilleure lecture des logs liés à l’exécution d’une étape de build bien précise. Les utilisateurs peuvent lier (2) des rapports supplémentaires à partir de leurs scripts de build.
L’image ci-dessous montre un exemple de comment les rapports complémentaires sont présentés à nos utilisateurs.
Failure Analytics
Develocity Failure Analytics est un outil précieux pour suivre un type d’erreur particulier, ses origines et les différents paramètres qui peuvent la rendre reproductible (système d’exploitation, repositories, version de la JVM, etc.). Cela nécessite de bien choisir les tags que nous mettons sur nos Build Scans, pour améliorer le rapport d’erreurs dans nos build Gradle afin de profiter au mieux de cette fonctionnalité.
Grâce à Failure Analytics, nous pouvons répertorier les sources d’échec ayant le plus d’impact. Dans l’image ci-dessus, nous utilisons des tags pour nous concentrer sur les échecs les plus impactants pour (1) les projets JVM lors de (2) tentatives de publication.
De même, le tableau de bord Test Failure Analytics de Develocity présenté ci-dessus permet à nos utilisateurs de suivre les performances d’un ou plusieurs tests au fil du temps. Cela inclut les performances et peut également nous renseigner sur de potentielles instabilités (flakyness).
Décrivez votre expérience globale avec Develocity et certaines de vos principales leçons apprises
“Nous n’avons que très peu de difficultés à maintenir Develocity : le produit fonctionne et est stable, et les mises à niveau sont généralement totalement indolores avec peu ou pas d’interruption de service.”
Emmanuel Guérin – Staff DevOps Engineer
En tant que fournisseur de services responsable de la santé globale d’un environnement de build vaste et complexe, Develocity est une bouffée d’air frais. Nous pouvons analyser rapidement et aider à résoudre les défis de build auxquels nos développeurs sont confrontés quotidiennement.
Develocity est très, très facile à installer en tant que serveur standalone: il suffit de suivre la documentation d’administration pour être opérationnel en un rien de temps. Nous avons également intégré la charte Helm assez facilement dans notre système de gestion de configuration basé sur Chef. Cela nous permet de démarrer une nouvelle instance de Develocity en quelques minutes.
Voici quelques conseils que nous pouvons proposer à d’autres équipes de développement qui débutent, sur la base de nos propres leçons apprises :
- Provisionner correctement votre environnement. Assurez-vous que vous disposez du matériel approprié pour prendre en charge vos cas d’utilisation avec Develocity. Par exemple, les performances du disque sont importantes si vous exécutez plusieurs milliers de builds par jour.
- Pour tirer le meilleur parti des Build Scans, prenez le temps de définir les paramètres appropriés. Tags, valeurs personnalisées et messages d’exception Gradle significatifs pour l’analyse des échecs. Cela vous évitera quelques maux de tête plus tard.
Quels projets d’avenir avez-vous pour Develocity?
En ce qui concerne la roadmap de notre équipe, nous prévoyons d’améliorer le caching de nos tâches Gradle, d’utiliser les reports JUnit avec d’autres langages que Java pour l’analyse des résultats de tests et de découvrir de nouvelles possibilités de reporting avec le kit Develocity Reporting & Visualization.