Dzięki opracowaniu automatycznego systemu testowania wydajności i monitorowania ich działanie zespół Lowe's Site Speed testuje przesyłanie żądań pod kątem budżetu wydajności i zapobiega powstawaniu spadków wydajności w środowisku produkcyjnym.
Lowe's to sklep dla majsterkowiczów o wartości prawie 90 miliardów dolarów, który prowadzi około 2200 sklepów i zatrudnia ponad 300 tys. współpracowników. Dzięki opracowaniu automatycznego systemu testowania i monitorowania, które zapobiega pogorszeniu wydajności w środowisku produkcyjnym, zespół Lowe's Site Speed Team mógł poprawić wydajność swojej witryny i zająć pozycję wśród czołowych witryn handlowych.
Problem
Celem zespołu Site Speed jest sprawić, by witryna Lowe'a była jedną z najszybszych witryn e-commerce pod względem szybkości wczytywania stron. Zanim firma Lowe stworzyła system automatycznego testowania i monitorowania, jej programiści nie mogli automatycznie mierzyć wydajności w środowiskach przedprodukcyjnych. Dotychczasowe narzędzia przeprowadzały testy wyłącznie w środowisku produkcyjnym. W rezultacie na etapie produkcyjnym zajęły się gorsze wersje, co źle wpływa na wrażenia użytkowników. Te gorsze kompilacje pozostaną w wersji produkcyjnej, dopóki nie zostaną wykryte przez zespół ds. szybkości witryny i wycofane przez autora.
Rozwiązanie
Zespół ds. szybkości witryny wykorzystał narzędzia typu open source do stworzenia zautomatyzowanego systemu testowania i monitorowania wydajności środowisk przedprodukcyjnych. System mierzy skuteczność każdego żądania pull i zabezpiecza PR przed wysyłką do produkcji, jeśli nie spełnia budżetu wydajności i kryteriów danych zespołu ds. szybkości witryny. System mierzy też zgodność z zasadami SEO i ADA.
Wpływ
Na podstawie próbki 1 zespołu, który w ciągu 16 tygodni wdrażających 102 kompilacje, automatyczny system testowania wydajności i monitorowania uniemożliwił wprowadzenie 32 kompilacji o niskiej wydajności.
Kiedy zespół ds. szybkości witryny informował programistów o przesłaniu regresji wydajności na platformę 3–5 dni, system automatycznie informuje programistów o problemach z wydajnością 5 minut po przesłaniu żądania pull w środowisku przedprodukcyjnym.
Jakość kodu poprawia się z czasem, co wynika z faktu, że z powodu regresji wydajności zgłaszanych jest mniej żądań pull. Zespół ds. szybkości witryny stopniowo zmniejsza budżet zarządzania, by stale poprawiać jakość witryn.
Ogólnie rzecz biorąc, jasne prawo własności do problematycznego kodu zmieniło kulturę inżynierów. Zamiast proaktywnie wprowadzać poprawki, ponieważ nigdy nie wiadomo, kto rzeczywiście wprowadził problem, zespół może wprowadzać aktywne optymalizacje, a własność problematycznego kodu jest przypisywana obiektywnie.
Implementacja
Sercem aplikacji Site Speed Manageance (SSG) jest Lighthouse CI. Aplikacja SSG wykorzystuje Lighthouse do sprawdzania i kontrolowania wydajności strony w przypadku każdego żądania pull.
Aplikacja SSG powoduje błąd kompilacji, jeśli nie osiągnięto określonego przez zespół ds. szybkości witryny budżetu wydajności i wartości docelowych danych. Egzekwuje nie tylko wydajność ładowania, ale także SEO, PWA i ułatwienia dostępu. Może natychmiast raportować stan autorom, weryfikatorom i zespołom SRE. Można też skonfigurować ją tak, aby pomijała sprawdzanie, gdy potrzebne są wyjątki.
Przepływ procesu automatycznego zarządzania szybkością (ASG)
Spinnaker
Punkt początkowy. Programista scala swój kod ze środowiskiem przedprodukcyjnym.
- Wdróż środowisko przedprodukcyjne z zasobami CDN.
- Sprawdź, czy wdrożenie się udało.
- Uruchom kontener Dockera, aby rozpocząć tworzenie aplikacji ASG, lub wyślij powiadomienie (w przypadku niepowodzenia wdrożenia).
Jenkins i Lighthouse
- Utwórz aplikację ASG z pomocą Jenkinsa.
- Uruchom niestandardowy kontener Dockera z zainstalowanymi przeglądarkami Chrome i Lighthouse.
Pobierz
lighthouserc.jsonz aplikacji SSG i uruchomlhci autorun --collect-url=https://example.com.
Aplikacja Jenkins i SSG
- Wyodrębnij kwotę
assertion-results.jsonz pliku lhci i porównaj ją z wstępnie zdefiniowanymi budżetami wbudgets.json. Zapisz dane wyjściowe w pliku tekstowym i prześlij je do Nexus do użycia w przyszłości. - Porównaj obecną kompilację
assertion-results.jsonz ostatnią udaną kompilacją (pobraną z Nexus) i zapisz ją jako plik tekstowy. - Utwórz e-maila w formacie HTML z informacjami o powodzeniu lub niepowodzeniu.
- Wyślij e-maila do odpowiednich list dystrybucyjnych przy użyciu Jenkinsa.