Che cos'è un ambiente di staging? La copia che non è mai davvero una copia

Un ambiente di staging è una copia funzionante della tua applicazione, vicina alla produzione quanto puoi permetterti, dove una release viene controllata prima che ci arrivino persone vere. Stesso codice, stessa forma della configurazione, stessa struttura del database, dati diversi e pubblico diverso.

L’idea è vecchia e semplice: provalo prima dove non conta. A renderla interessante è che lo staging non è mai davvero una copia, e ogni problema che non riesce a intercettare nasce da quella distanza.

Tra cosa sta

La maggior parte dei team finisce con tre o quattro ambienti, e le differenze riguardano chi ha il permesso di romperli.

• Locale è la macchina di chi sviluppa. Si rompe di continuo, e non importa a nessuno.
• Lo staging esegue il codice che sta per uscire, con dati che nessuno rimpiangerà. Si rompe ogni tanto, e importa un po’ a qualcuno.
• La produzione è dove stanno i clienti.

Alcuni team aggiungono un quarto ambiente tra staging e produzione per i test di carico o di integrazione, altri mettono un ambiente di anteprima per ogni branch prima dello staging. I nomi variano più delle idee.

A cosa serve

Intercettare quello che una suite di test non può. Migrazioni su un database con volumi veri. Asset che vengono compilati solo durante un deploy. Un valore di configurazione che esiste su una macchina e non su un’altra. Nessun test unitario tocca niente di tutto questo.

Provare il deploy stesso. Una release è una procedura, e anche la procedura ha i suoi bug. Se il deploy sullo staging è lo stesso comando del deploy in produzione, hai fatto le prove di quello che altrimenti verrebbe fatto per la prima volta nel momento peggiore.

Dare a chi non sviluppa un posto dove guardare. Il collaudo, una dimostrazione, uno screenshot per il supporto - tutti hanno bisogno di un posto reale che non sia reale.

Come lo staging si allontana

Questa è la parte che vale la pena mettere per iscritto, perché un ambiente di staging che nessuno mantiene è peggio di nessun ambiente: produce fiducia invece che informazioni.

Il codice si allontana. Tutto ciò che viene unito finisce sullo staging in automatico; la produzione viene rilasciata quando qualcuno lo decide. Uno staging trenta commit avanti rispetto alla produzione ti racconta di un software che i tuoi clienti non hanno, e il bug che non riesci a riprodurre sullo staging lì potrebbe semplicemente essere già risolto.

I dati si allontanano. La produzione accumula quindici anni di decisioni - account senza indirizzo e-mail, un ordine di prima che esistesse una colonna, un nome con un apostrofo. Lo staging ha quello che ci hanno messo i seed. La maggior parte dei difetti che arrivano ai clienti vive in forme di dati che nessuno ha pensato di creare.

La configurazione si allontana. Una chiave impostata su un host e non sull’altro, un feature flag acceso in un posto solo, un servizio esterno puntato su una sandbox che si comporta diversamente da quello vero. È la classe di problemi per cui lo staging esiste ed è la classe che più spesso causa.

La scala si allontana. Un processo web contro dodici, un database con mille righe contro dieci milioni. Una query istantanea sullo staging può essere il motivo per cui la produzione cade.

Tenere onesta la distanza

La distanza non si può chiudere, quindi l’obiettivo è sapere dov’è.

• Rilascia allo stesso modo su entrambi. Un comando, uno script, nessun passaggio manuale che esista in un posto solo. Se la produzione ha un passaggio che lo staging non ha, quel passaggio non è mai stato provato.
• Rilasciali insieme quando una modifica riguarda entrambi. Qualsiasi cosa abbia un client - un’estensione del browser, un’app mobile, un’integrazione con un partner - che parla con un ambiente e non con l’altro non è in linea in nessuno dei due, per chi sta provando.
• Usa dati con la forma della produzione, non i dati di produzione. Anonimizzati o generati, con le forme scomode incluse di proposito: l’account vuoto, l’elenco enorme, l’apostrofo. Copiare dati veri dei clienti in un ambiente meno protetto è un incidente sulla privacy in attesa di una data.
• Tienilo spento quando non serve, e aspettati che sia un bersaglio: gli ambienti di staging sono noti per essere meno aggiornati e più aperti dei sistemi che rispecchiano.
• Di’ qual è quale. Un banner, un colore, qualsiasi cosa. Prima o poi qualcuno farà una dimostrazione in produzione o un test distruttivo sull’host sbagliato, e impedirlo costa una riga di CSS.

Quando lo staging dice una cosa e la produzione ne dice un’altra

Non è un fallimento dello staging, è l’informazione che lo staging esiste per darti, ed è il momento di scoprire quale delle quattro derive qui sopra lo spiega.

La prima domanda è quale build sta girando su ciascuno. La seconda è se la stessa cosa succede con gli stessi dati. Sono entrambe cose che una segnalazione dovrebbe dire, ed entrambe i dettagli che mancano regolarmente a “sullo staging funziona”.

Una cattura da ciascun ambiente trasforma una discussione in un confronto: gli stessi passaggi, due serie di output della console e di registri di rete, e di solito una differenza evidente. La guida alla segnalazione di bug ha il resto di quello che va incluso, e nominare l’ambiente è la riga che si dimentica.

La versione breve

Lo staging è una prova generale, non una copia. Il suo valore è proporzionale all’onestà con cui tieni traccia dei modi in cui si differenzia dalla produzione - codice, dati, configurazione e scala - e una differenza che conosci è un limite, mentre una che hai dimenticato è un falso negativo travestito da spunta verde.