Dzięki stworzeniu automatycznego systemu testowania i monitorowania wydajności zespół ds. szybkości witryny w Lowe testuje żądania pobierania pod kątem budżetu wydajności i zapobiega regresji wydajności w produkcji.
Lowe's to sieć sklepów budowlanych o wartości prawie 90 mld USD, która prowadzi około 2200 sklepów i zatrudnia ponad 300 tys. osób. Dzięki stworzeniu automatycznego systemu testowania i monitorowania, który zapobiega regresji wydajności podczas wdrażania w produkcji, zespół ds. szybkości witryny w Lowe poprawił wydajność swojej witryny, dzięki czemu znalazł się w rankingu najlepszych witryn handlowych.
Problem
Celem zespołu ds. szybkości witryny jest sprawienie, aby witryna Lowe's była jedną z najszybszych witryn e-commerce pod względem szybkości wczytywania stron. Zanim stworzyli system automatycznego testowania i monitorowania, deweloperzy witryny firmy Lowe nie mogli automatycznie mierzyć skuteczności w środowiskach przedprodukcyjnych. Istniejące narzędzia przeprowadzały testy tylko w środowisku produkcyjnym. W rezultacie do wersji produkcyjnej trafiły gorsze wersje, co pogorszyło wrażenia użytkowników. Te gorsze wersje pozostawałyby w produkcji, dopóki zespół ds. szybkości witryn nie wykrył ich i nie cofnąłby ich autor.
Rozwiązanie
Zespół ds. szybkości witryny użył narzędzi open source do tworzenia automatycznego systemu testowania i monitorowania wydajności w środowiskach przedprodukcyjnych. System mierzy skuteczność każdego zgłoszenia pull request (PR) i blokuje wdrożenie PR do wersji produkcyjnej, jeśli nie spełnia budżetu skuteczności i kryteriów danych zespołu ds. szybkości witryn. System mierzy też zgodność z SEO i ADA.
Wpływ
W przypadku 1 zespołu, który w ciągu 16 tygodni wdrożył 102 kompilacje, automatyczny system testowania i monitorowania skuteczności uniemożliwił wdrożenie 32 kompilacji o niezadowalającej skuteczności.
Wcześniej zespół ds. szybkości witryny potrzebował 3–5 dni na poinformowanie deweloperów o tym, że wdrożenie regresji wydajności w produkcji, teraz system automatycznie informuje deweloperów o problemach z wydajnością 5 minut po przesłaniu żądania pull w środowisku przedprodukcyjnym.
Jakość kodu poprawia się z upływem czasu, co widać po tym, że mniej zgłoszeń o pull request jest oznaczanych jako regresja wydajności. Zespół ds. szybkości witryny stopniowo zmniejsza budżety zarządzania, aby stale poprawiać jakość witryny.
Ogólnie rzecz biorąc, jasne określenie właściciela problematycznego kodu zmieniło kulturę inżynierską. Zamiast wprowadzać poprawki w reakcji na problemy, ponieważ nigdy nie było jasne, kto tak naprawdę je spowodował, zespół może wprowadzić proaktywne optymalizacje, przypisując własność problematycznego kodu do obiektywnego właściciela.
Implementacja
Sercem aplikacji do zarządzania szybkością witryny jest Lighthouse CI. Aplikacja SSG używa Lighthouse do sprawdzania i weryfikowania wydajności strony każdego żądania pull.
Aplikacja SSG powoduje niepowodzenie kompilacji, jeśli nie zostaną osiągnięte budżet wydajności i cele dotyczące wskaźników określone przez zespół ds. szybkości witryny. Obejmuje ona nie tylko wydajność wczytywania, ale też SEO, PWA i dostępność. Może ona natychmiast przekazywać stan autorom, weryfikatorom i zespołom SRE. Możesz też skonfigurować go tak, aby pomijał sprawdzanie w przypadku wyjątków.
Przepływ procesu automatycznego zarządzania prędkością (ASG)
Spinnaker
Punkt początkowy. Programista łączy kod ze środowiskiem przedprodukcyjnym.
- Wdróż środowisko przedprodukcyjne z komponentami CDN.
- Sprawdź, czy wdrożenie przebiegło pomyślnie.
- Uruchom kontener Docker, aby rozpocząć kompilowanie aplikacji ASG lub wysłać powiadomienie (w przypadku niepowodzenia wdrożenia).
Jenkins i Lighthouse
- Utwórz aplikację ASG za pomocą Jenkinsa.
- Uruchom niestandardowy kontener Dockera z zainstalowanymi Chrome i Lighthouse.
Pobierz
lighthouserc.jsonz aplikacji SSG i uruchomlhci autorun --collect-url=https://example.com.
Aplikacja Jenkins i SSG
- Wyodrębnij
assertion-results.jsonz LHCI i porównaj go z wstępnie zdefiniowanymi budżetami wbudgets.json. Zapisz dane wyjściowe w pliku tekstowym i prześlij je do Nexus na potrzeby przyszłych porównań. - Porównaj bieżący plik
assertion-results.jsonz ostatnią udaną kompilacją (pobraną z Nexusa) i zapisz go jako plik tekstowy. - Utwórz e-maila HTML z informacjami o powodzeniu lub niepowodzeniu.
- Wyślij e-maila do odpowiednich list dystrybucyjnych za pomocą Jenkinsa.