Creando un sistema automatizzato di test e monitoraggio delle prestazioni, il team Site Speed di Lowe's Site Speed verifica le richieste di pull rispetto ai budget per le prestazioni e impedisce che le regressioni delle prestazioni entrino in produzione.
Lowe's è un rivenditore di articoli per la casa da quasi 90 miliardi di dollari, che gestisce circa 2200 negozi e impiega più di 300.000 dipendenti. Creando un sistema automatizzato di test e monitoraggio che impedisce il deployment delle regressioni in produzione, il team Site Speed di Lowe è riuscito a migliorare le prestazioni del suo sito web, posizionandosi tra i principali siti di vendita al dettaglio.
Problema
L'obiettivo del team di Velocità del sito è rendere il sito di Lowe uno dei siti di e-commerce più veloci in termini di rendimento di caricamento delle pagine. Prima di creare il sistema automatizzato di test e monitoraggio, gli sviluppatori del sito web di Lowe non erano in grado di misurare automaticamente le prestazioni negli ambienti di pre-produzione. Gli strumenti esistenti hanno condotto solo test nell'ambiente di produzione. Di conseguenza, le build di livello inferiore sono entrate in produzione, creando un'esperienza utente scadente. Queste build di livello inferiore rimarrebbero in produzione fino a quando non verranno rilevate dal team Site Speed e ripristinate dall'autore.
Soluzione
Il team Site Speed ha utilizzato strumenti open source per creare un sistema automatizzato di test e monitoraggio delle prestazioni per gli ambienti di pre-produzione. Il sistema misura le prestazioni di ogni richiesta di pull (PR) e limita il PR dalla spedizione alla produzione se non soddisfa il budget di prestazioni e i criteri delle metriche del team dedicato alla velocità del sito. Inoltre, il sistema misura la conformità a SEO e ADA.
Impatto
Da un campione di un team in 16 settimane di deployment di 102 build, il sistema di monitoraggio e test delle prestazioni automatizzati ha impedito l'ingresso in produzione di 32 build con prestazioni inferiori alle aspettative.
Mentre prima il team Velocità sito impiegava da tre a cinque giorni per informare gli sviluppatori dell'invio in produzione delle regressioni delle prestazioni, ora il sistema informa automaticamente gli sviluppatori dei problemi di prestazioni cinque minuti dopo l'invio di una richiesta di pull in un ambiente di pre-produzione.
La qualità del codice migliora nel tempo, in base al fatto che vengono segnalate meno richieste di pull per regressioni delle prestazioni. Inoltre, il team di Velocità del sito sta aumentando gradualmente i budget di governance per migliorare continuamente la qualità del sito.
In generale, avere una chiara proprietà del codice problematico ha cambiato la cultura ingegneristica. Invece di fare correzioni reattive perché non era mai chiaro chi abbia effettivamente introdotto i problemi, il team può ottimizzare proattivamente la proprietà del codice problematico attribuibile oggettivamente.
Implementazione
Il cuore dell'app Site Speed Governance (SSG) è Lighthouse CI. L'app SSG utilizza Lighthouse per convalidare e controllare le prestazioni delle pagine di ogni richiesta di pull.
L'app SSG causa un errore di build se il budget delle prestazioni e i target delle metriche definiti dal team Velocità sito non vengono raggiunti. Non vengono applicate solo le prestazioni di caricamento, ma anche la SEO, le PWA e l'accessibilità. Può segnalare immediatamente lo stato ad autori, revisori e team SRE. Può anche essere configurato in modo da bypassare i controlli quando sono necessarie eccezioni.
Flusso dei processi di governance della velocità automatizzata (ASG)
Spinnaker
Punto di partenza. Uno sviluppatore unisce il proprio codice in un ambiente di pre-produzione.
- Esegui il deployment dell'ambiente di pre-produzione con asset CDN.
- Verifica che il deployment sia riuscito.
- Esegui un container Docker per iniziare a creare l'applicazione ASG o invia una notifica (in caso di errore del deployment).
Jenkins e Lighthouse
- Crea l'applicazione ASG con Jenkins.
- Esegui un container Docker personalizzato in cui sono installati Chrome e Lighthouse.
Esegui il pull di
lighthouserc.json
dall'app SSG ed eseguilhci autorun --collect-url=https://example.com
.
App Jenkins e SSG
- Estrai
assertion-results.json
da lhci e confrontalo con i budget predefiniti inbudgets.json
. Salva l'output come file di testo e caricalo su Nexus per confrontarlo in futuro. - Confronta l'attuale
assertion-results.json
con l'ultima build riuscita (scaricata da Nexus) e salvala come file di testo. - Crea un'email HTML contenente le informazioni sull'esito positivo o negativo.
- Invia l'email alle liste di distribuzione pertinenti con Jenkins.