En créant un système automatisé de test et de surveillance des performances, l'équipe chargée de la vitesse des sites Lowe's teste les demandes d'extraction en fonction des budgets de performances et empêche les régressions de performances d'être déployées en production.
Lowe's est un marchand de produits de bricolage qui réalise un chiffre d'affaires de près de 90 milliards de dollars, gère environ 2 200 magasins et emploie plus de 300 000 collaborateurs. En créant un système de test et de surveillance automatisé qui empêche les régressions de performances d'être déployées en production, l'équipe chargée de la vitesse des sites Lowe's a pu améliorer les performances de son site Web, qui se classe parmi les meilleurs sites marchands.
Problème
L'objectif de l'équipe chargée de la vitesse du site est de faire du site Lowe's l'un des sites d'e-commerce les plus rapides en termes de performances de chargement des pages. Avant de créer leur système de test et de surveillance automatisés, les développeurs du site Web de Lowe ne pouvaient pas mesurer automatiquement les performances dans les environnements de préproduction. Les outils existants ne permettaient de réaliser des tests que dans l'environnement de production. Par conséquent, des builds de mauvaise qualité ont été mis en production, ce qui a entraîné une mauvaise expérience utilisateur. Ces builds inférieurs restaient en production jusqu'à ce qu'ils soient détectés par l'équipe chargée de la vitesse des sites et annulés par l'auteur.
Solution
L'équipe chargée de la vitesse des sites a utilisé des outils Open Source pour créer un système automatisé de test et de surveillance des performances pour les environnements de préproduction. Le système mesure les performances de chaque requête pull (PR) et empêche la PR d'être mise en production si elle ne répond pas au budget de performances et aux critères de métrique de l'équipe Site Speed. Le système mesure également la conformité aux principes du référencement naturel et de l'ADA.
Impact
Sur un échantillon d'une équipe qui a déployé 102 builds sur 16 semaines, le système automatisé de test et de surveillance des performances a empêché le déploiement en production de 32 builds dont les performances étaient insuffisantes.
Alors qu'il fallait auparavant trois à cinq jours à l'équipe Site Speed pour informer les développeurs qu'ils avaient envoyé des régressions de performances en production, le système informe désormais automatiquement les développeurs des problèmes de performances cinq minutes après l'envoi d'une requête pull dans un environnement de préproduction.
La qualité du code s'améliore au fil du temps, comme en témoignent les requêtes pull signalées pour des régressions de performances. L'équipe chargée de la vitesse des sites resserre également progressivement les budgets de gouvernance pour améliorer continuellement la qualité des sites.
En général, la clarté de la propriété du code problématique a modifié la culture de l'ingénierie. Au lieu de faire des corrections réactives à contrecœur, car il n'a jamais été clair qui a réellement introduit les problèmes, l'équipe peut effectuer des optimisations proactives, car la propriété du code problématique peut être attribuée de manière objective.
Implémentation
L'application de gouvernance de la vitesse du site (SSG, Site Speed Governance) repose sur Lighthouse CI. L'application SSG utilise Lighthouse pour valider et auditer les performances des pages de chaque requête pull.
L'application SSG entraîne l'échec d'une compilation si les objectifs de performances et les métriques définis par l'équipe chargée de la vitesse du site ne sont pas atteints. Il applique non seulement les performances de chargement, mais aussi le référencement SEO, les PWA et l'accessibilité. Il peut signaler immédiatement l'état aux auteurs, aux examinateurs et aux équipes SRE. Il peut également être configuré pour contourner les vérifications en cas d'exceptions.
Flux de processus de gouvernance de la vitesse automatisée (ASG)
Spinnaker
Point de départ. Un développeur fusionne son code dans un environnement de préproduction.
- Déployez l'environnement de préproduction avec des éléments CDN.
- Vérifiez que le déploiement a réussi.
- Exécutez un conteneur Docker pour commencer à compiler l'application ASG ou envoyer une notification (en cas d'échec du déploiement).
Jenkins et Lighthouse
- Créez l'application ASG avec Jenkins.
- Exécutez un conteneur Docker personnalisé sur lequel Chrome et Lighthouse sont installés.
Extrayez
lighthouserc.jsonde l'application SSG et exécutezlhci autorun --collect-url=https://example.com.
Application Jenkins et SSG
- Extrayez
assertion-results.jsonde lhci et comparez-le aux budgets prédéfinis dansbudgets.json. Enregistrez la sortie au format texte et importez-la dans Nexus pour effectuer des comparaisons ultérieures. - Comparez le
assertion-results.jsonactuel à la dernière compilation réussie (téléchargée depuis Nexus) et enregistrez-le sous forme de fichier texte. - Créez un e-mail HTML contenant les informations sur la réussite ou l'échec.
- Envoyez l'e-mail aux listes de distribution appropriées avec Jenkins.