Mithilfe eines automatisierten Systems für Leistungstests und -überwachung testet das Site Speed-Team von Lowe Pull-Anfragen mit Leistungsbudgets und verhindert so, dass Leistungseinbußen in die Produktion übergehen.
Lowe's ist ein Baumarkt im Wert von fast 90 Milliarden US-Dollar, der etwa 2.200 Geschäfte betreibt und mehr als 300.000 Mitarbeiter beschäftigt. Das Site Speed-Team von Lowe hat ein automatisiertes Test- und Monitoringsystem entwickelt, das Leistungseinbußen in der Produktion verhindert. Dadurch konnte das Site Speed-Team von Lowe die Leistung seiner Website verbessern und zählte zu den Top-Händlern.
Problem
Das Website-Geschwindigkeits-Team möchte die Website von Lowe zu einer der schnellsten E-Commerce-Websites im Hinblick auf die Seitenladeleistung machen. Vor der Entwicklung ihres automatisierten Test- und Monitoringsystems konnten die Websiteentwickler von Lowe die Leistung in Vorproduktionsumgebungen nicht automatisch messen. Bei den vorhandenen Tools wurden nur Tests in der Produktionsumgebung durchgeführt. Daher fielen minderwertige Builds in die Produktion, was zu einer schlechten Nutzererfahrung führt. Diese minderwertigen Builds blieben so lange in der Produktion, bis sie vom Site Speed-Team erkannt und vom Autor zurückgesetzt wurden.
Lösung
Das Site Speed-Team entwickelte mithilfe von Open-Source-Tools ein automatisiertes System für Leistungstests und -überwachung für Vorproduktionsumgebungen. Das System misst die Leistung jeder Pull-Anfrage (PR) und sperrt den PR vom Versand bis zur Produktion, wenn es nicht dem Leistungsbudget und den Messwertkriterien des Teams für Websitegeschwindigkeit entspricht. Das System misst auch die SEO- und ADA-Konformität.
Auswirkungen
Aus einer Stichprobe von einem Team, das über einen Zeitraum von 16 Wochen 102 Builds bereitgestellt hat, hat das automatisierte System für Leistungstests und -überwachung verhindert, dass 32 Builds mit unterdurchschnittlicher Leistung in Produktion gehen.
Bisher dauerte es drei bis fünf Tage, bis das Site Speed-Team Entwickler darüber informiert hatte, dass Leistungsabfälle in die Produktion übernommen wurden. Jetzt informiert das System die Entwickler fünf Minuten nach Einreichung einer Pull-Anfrage in einer Vorproduktionsumgebung automatisch über Leistungsprobleme.
Die Codequalität verbessert sich im Laufe der Zeit, gemessen daran, dass weniger Pull-Anfragen für Leistungsabfälle gemeldet werden. Das Team für die Websitegeschwindigkeit verschärft außerdem nach und nach die Governance-Budgets, um die Qualität der Website kontinuierlich zu verbessern.
Im Allgemeinen hat die klare Verantwortlichkeit für problematischen Code die Entwicklungskultur verändert. Anstatt reaktive Korrekturen abzulegen, weil nie klar war, wer die Probleme tatsächlich verursacht hat, kann das Team proaktive Optimierungen vornehmen, bei denen die Inhaberschaft des problematischen Codes objektiv zugeordnet werden kann.
Implementierung
Das Herzstück der SSG-Anwendung (Site Speed Governance) ist Lighthouse CI. Die SSG-Anwendung verwendet Lighthouse, um die Seitenleistung jeder Pull-Anfrage zu validieren und zu prüfen.
Die SSG-Anwendung führt dazu, dass ein Build fehlschlägt, wenn das vom Team für Websitegeschwindigkeit festgelegte Leistungsbudget und die Messwerte nicht erreicht werden. Er erzwingt nicht nur die Ladeleistung, sondern auch die Suchmaschinenoptimierung, PWA und Barrierefreiheit. Sie kann Autoren, Prüfer und SRE-Teams sofort den Status melden. Er kann auch so konfiguriert werden, dass die Prüfungen umgangen werden, wenn Ausnahmen erforderlich sind.
Automated Speed Governance (ASG)-Prozessablauf
Spinnaker
Startpunkt. Ein Entwickler führt seinen Code in einer Vorproduktionsumgebung zusammen.
- Vorproduktionsumgebung mit CDN-Assets bereitstellen
- Prüfen Sie, ob die Bereitstellung erfolgreich war.
- Führen Sie einen Docker-Container aus, um mit dem Erstellen der ASG-Anwendung zu beginnen, oder senden Sie eine Benachrichtigung (falls ein Bereitstellungsfehler auftritt).
Jenkins und Lighthouse
- Die ASG-Anwendung mit Jenkins erstellen
- Einen benutzerdefinierten Docker-Container ausführen, in dem Chrome und Lighthouse installiert sind
Rufen Sie
lighthouserc.jsonaus der SSG-App ab und führen Sielhci autorun --collect-url=https://example.comaus.
Jenkins- und SSG-Anwendung
- Extrahieren Sie
assertion-results.jsonaus lhci und vergleichen Sie es mit vordefinierten Budgets inbudgets.json. Speichern Sie die Ausgabe als Textdatei und laden Sie sie für zukünftige Vergleiche auf Nexus hoch. - Vergleichen Sie den aktuellen
assertion-results.jsonmit dem letzten erfolgreichen Build, der von Nexus heruntergeladen wurde, und speichern Sie ihn als Textdatei. - Erstellen Sie eine HTML-E-Mail mit den Erfolgs- oder Fehlerinformationen.
- Senden Sie die E-Mail mit Jenkins an die relevanten Verteilerlisten.