Durch die Entwicklung eines automatisierten Systems für Leistungstests und -überwachung prüft das Team für die Websitegeschwindigkeit von Lowe's Pull-Anfragen auf Einhaltung der Leistungsbudgets und verhindert Leistungsrückgänge in der Produktion.
Lowe's ist ein Baumarkt mit einem Umsatz von fast 90 Milliarden $, der etwa 2.200 Geschäfte betreibt und mehr als 300.000 Mitarbeiter beschäftigt. Durch die Entwicklung eines automatisierten Test- und Überwachungssystems, das Leistungsrückgänge bei der Bereitstellung in der Produktion verhindert, konnte das Team für die Websitegeschwindigkeit von Lowe's die Leistung seiner Website verbessern und sich unter den Top-Einzelhandelswebsites platzieren.
Problem
Das Ziel des Websitegeschwindigkeitsteams ist es, die Website von Lowe's zu einer der schnellsten E-Commerce-Websites in Bezug auf die Seitenladeleistung zu machen. Bevor das automatisierte Test- und Monitoringsystem entwickelt wurde, konnten die Website-Entwickler von Lowe die Leistung nicht automatisch in Vorproduktionsumgebungen messen. Mit den vorhandenen Tools wurden nur Tests in der Produktionsumgebung durchgeführt. Infolgedessen gelangten minderwertige Builds in die Produktion, was zu einer schlechten Nutzererfahrung führte. Diese minderwertigen Builds blieben in der Produktion, bis sie vom Site Speed-Team erkannt und vom Autor rückgängig gemacht wurden.
Lösung
Das Team für die Websitegeschwindigkeit hat mit Open-Source-Tools ein automatisiertes System für Leistungstests und -überwachung für Vorproduktionsumgebungen entwickelt. Das System misst die Leistung jedes Pull-Requests (PR) und verhindert die Bereitstellung des PR in der Produktion, wenn er nicht die Leistungsziele und Messkriterien des Site Speed-Teams erfüllt. Das System misst auch die SEO- und ADA-Compliance.
Auswirkungen
In einer Stichprobe von einem Team, das über 16 Wochen hinweg 102 Builds bereitgestellt hat, konnte das automatisierte System für Leistungstests und ‑überwachung verhindern, dass 32 Builds mit unterdurchschnittlicher Leistung in die Produktion übernommen wurden.
Früher brauchte das Site Speed-Team drei bis fünf Tage, um Entwickler darüber zu informieren, dass sie Leistungseinbußen in die Produktion gebracht hatten. Jetzt werden Entwickler fünf Minuten nach dem Einreichen eines Pull-Requests in einer Vorproduktionsumgebung automatisch über Leistungsprobleme informiert.
Die Codequalität verbessert sich im Laufe der Zeit, was sich daran zeigt, dass weniger Pull-Anfragen auf Leistungsrückgänge gemeldet werden. Das Team für die Websitegeschwindigkeit strafft außerdem nach und nach die Budgets für die Verwaltung, um die Websitequalität kontinuierlich zu verbessern.
Im Allgemeinen hat die klare Zuordnung von problematischem Code die Engineering-Kultur verändert. Anstatt unzufrieden reagieren zu müssen, weil nie klar war, wer die Probleme tatsächlich verursacht hat, kann das Team proaktive Optimierungen vornehmen, da die Zuständigkeit für problematischen Code objektiv zugeordnet werden kann.
Implementierung
Das Herzstück der App „Site Speed Governance“ (SSG) ist Lighthouse CI. Die SSG-App verwendet Lighthouse, um die Seitenleistung jedes Pull-Requests zu validieren und zu prüfen.
Die SSG-App führt zu einem Build-Fehler, wenn das vom Team für die Websitegeschwindigkeit festgelegte Leistungsbudget und die Messwertziele nicht erreicht werden. Sie erzwingen nicht nur die Ladeleistung, sondern auch SEO, PWA und Barrierefreiheit. Der Status kann sofort an Autoren, Prüfer und SRE-Teams gesendet werden. Sie können auch konfigurieren, dass die Prüfungen bei Bedarf umgangen werden.
Ablauf des automatisierten Geschwindigkeitsmanagements (ASG)
Spinnaker
Startpunkt. Ein Entwickler führt einen Code-Merge in einer Vorproduktionsumgebung durch.
- Stellen Sie die Vorproduktionsumgebung mit CDN-Assets bereit.
- Prüfen Sie, ob die Bereitstellung erfolgreich war.
- Einen Docker-Container ausführen, um mit dem Erstellen der ASG-Anwendung zu beginnen oder eine Benachrichtigung zu senden (bei einem Bereitstellungsfehler).
Jenkins und Lighthouse
- Erstellen Sie die ASG-Anwendung mit Jenkins.
- Einen benutzerdefinierten Docker-Container ausführen, in dem Chrome und Lighthouse installiert sind
Rufe
lighthouserc.jsonaus der SSG App ab und führelhci autorun --collect-url=https://example.comaus.
Jenkins- und SSG-App
- Extrahieren Sie
assertion-results.jsonaus lhci und vergleichen Sie sie mit den vordefinierten Budgets inbudgets.json. Speichern Sie die Ausgabe als Textdatei und laden Sie sie für zukünftige Vergleiche in Nexus hoch. - Vergleichen Sie die aktuelle
assertion-results.jsonmit dem letzten erfolgreichen Build (von Nexus heruntergeladen) und speichern Sie sie als Textdatei. - Erstellen Sie eine HTML-E-Mail mit den Informationen zum Erfolg oder Misserfolg.
- Senden Sie die E-Mail mit Jenkins an die entsprechenden Verteilerlisten.