Gli ambienti di staging sono una di quelle buone abitudini professionali che sembrano un peso finché non ti salvano. «È solo una piccola modifica», si pensa. «Modifico il sito in produzione, aggiorno e ho finito.» La maggior parte delle volte funziona. Le poche volte che non funziona, il costo si traduce in ore di recupero, clienti persi o un sabato intero passato a riparare quella che avrebbe dovuto essere una modifica del martedì.
Tre situazioni reali degli ultimi due anni in Defyn, anonimizzate ma leggermente romanzate. In ogni caso, una modifica di cinque minuti fatta sul sito in produzione è costata tra mezza giornata e una settimana intera. In ogni caso, un ambiente di staging avrebbe individuato il problema prima che raggiungesse un cliente.
Storia 1: L’aggiornamento del plugin che si è mangiato il checkout
Un sito di e-commerce con WooCommerce ha applicato un aggiornamento di plugin di routine un sabato pomeriggio, direttamente in produzione. Un plugin gateway di pagamento ha ricevuto un piccolo salto di versione. Il titolare del sito ha cliccato su aggiorna, la dashboard è diventata verde ed è uscito a cena.
Quello che non sapeva era che la nuova versione aveva introdotto una piccola modifica nel modo in cui veniva sanificato il formato dei campi della carta di credito. Sul sito, con la versione di PHP dell’agenzia, tutto funzionava bene. Sulla versione di PHP più vecchia dell’hosting, il gateway generava un errore silenzioso a ogni transazione. I pagamenti hanno iniziato a fallire immediatamente.
Domenica mattina, quando il titolare ha controllato, 31 clienti avevano incontrato il checkout guasto e avevano rinunciato. Il plugin è stato ripristinato entro un’ora, ma quei 31 clienti non sono mai tornati. Un ambiente di staging con una sola transazione di prova lo avrebbe individuato prima di perdere un solo ordine reale.
Storia 2: La modifica CSS che ha rotto il mobile
Un sito di servizi B2B aveva bisogno di una piccola modifica visiva. Un pulsante sulla home page doveva essere leggermente più grande e di una tonalità di rosso diversa. La responsabile marketing ha aperto il personalizzatore, ha fatto la modifica, ha salvato e ha considerato la cosa conclusa.
La modifica ha rotto il layout mobile. Il pulsante ora fuoriusciva dal contenitore su schermi larghi meno di 400 pixel, spingendo il resto della pagina di lato e facendo andare a capo in modo sgraziato il menu di navigazione. La responsabile marketing non ha mai aperto il sito su un telefono, quindi non se n’è accorta.
L’agenzia l’ha scoperto tre settimane dopo, durante una revisione trimestrale. A quel punto, tre settimane di traffico mobile (che era il 60 per cento del pubblico del sito) avevano visto una home page rotta. La frequenza di rimbalzo su mobile era salita silenziosamente del 18 per cento in quel periodo.
Storia 3: L’aggiornamento del tema che ha perso la home page
Il tema WordPress di un cliente aveva disponibile una versione principale. Le note di rilascio promettevano miglioramenti delle prestazioni e alcune nuove funzionalità. Il cliente ha applicato l’aggiornamento un venerdì pomeriggio. Il sito si è ricostruito e l’intero layout della home page era sparito. Sostituito da un modello predefinito fornito con la nuova versione del tema.
La versione principale aveva cambiato il modo in cui il tema memorizzava i dati di layout, e lo script di migrazione è stato eseguito in modo imperfetto sul database in produzione. Il recupero ha richiesto di ripristinare la versione precedente del tema, reimportare manualmente il layout della home page da un backup e riapplicare tre settimane di modifiche incrementali. Tempo totale di recupero: 11 ore in un lungo fine settimana.
Su una copia di staging, il guasto sarebbe stato visibile in 30 secondi. L’agenzia avrebbe segnalato quella versione del tema come rischiosa e avrebbe consigliato un’altra via di aggiornamento. Zero tempi di inattività per il cliente, zero fine settimana perso.
Cos’è davvero un ambiente di staging
Un ambiente di staging è una copia privata del sito in produzione, ospitata su un URL diverso, che rispecchia la produzione il più fedelmente possibile. La versione del tema corrisponde, le versioni dei plugin corrispondono, i contenuti sono recenti e il database è ragionevolmente aggiornato. Il team apporta lì le modifiche, le testa e le porta in produzione solo dopo aver confermato che funzionano.
I moderni hosting WordPress gestiti (Pantheon, WP Engine, Kinsta, SiteHost) offrono tutti lo staging con un clic. La maggior parte degli hosting di qualità lo include nei propri piani. Configurarlo per la prima volta su un hosting gestito è un lavoro da 10 minuti, dopodiché resta lì a tempo indeterminato come un’assicurazione economica.
La questione della disciplina
La configurazione tecnica è facile. La parte più difficile è l’abitudine. «È solo una piccola modifica» deve sparire dal vocabolario del team. Ogni aggiornamento di plugin, ogni aggiornamento di tema e ogni modifica strutturale al CSS passa prima dallo staging. Punto.
Le modifiche ai contenuti (cambi di testo, sostituzione di un’immagine in evidenza, pubblicazione di un nuovo articolo del blog) possono di solito saltare lo staging senza rischi. Le modifiche strutturali e infrastrutturali no.
Se il tuo sito non ha un ambiente di staging, o ne ha uno che nessuno usa davvero, il team di sviluppo WordPress di Defyn può predisporlo e impostare un flusso di lavoro sensato. Una volta che un team dispone di un processo di staging funzionante da tre mesi, nessuno vuole più modificare il sito in produzione direttamente.
