Quasi ogni progetto software parla di «sviluppo», «test» e «produzione». Ma spesso questi ambienti sono così diversi tra loro che un test superato in uno non dice nulla sull'altro. Lo sviluppatore usa SQLite, la produzione PostgreSQL; staging gira su una macchina piccola con dati vecchi di un anno; la configurazione cambia a mano in ogni posto. Un buon assetto degli ambienti è ciò che rende davvero affidabili i test e i rilasci.
A cosa serve ciascun ambiente
- Sviluppo: il computer dello sviluppatore o un ambiente personale. Deve essere rapido da avviare e facile da distruggere e ricreare.
- Test o integrazione: dove la pipeline esegue i test automatici a ogni modifica, spesso in ambienti temporanei che durano pochi minuti.
- Staging: una copia il più possibile fedele della produzione, dove si verifica la versione candidata al rilascio prima che raggiunga gli utenti.
- Produzione: l'ambiente reale, con utenti e dati veri.
Non tutti i progetti hanno bisogno di quattro livelli. Per un'applicazione piccola possono bastare sviluppo e produzione, purché la pipeline esegua test seri. Ma se esiste uno staging, deve servire a qualcosa: uno staging che non somiglia alla produzione dà solo una falsa sicurezza.
La parità tra ambienti
Gli ambienti dovrebbero differire il meno possibile. Le differenze più insidiose sono di tre tipi.
Differenze di software
Usare un database diverso in sviluppo, una versione diversa del linguaggio o un sistema operativo diverso fa emergere i problemi solo in produzione. I container sono lo strumento più efficace per ridurre questo divario: la stessa immagine, con le stesse versioni, gira ovunque. Anche i servizi accessori, come database, code e cache, possono girare in container identici a quelli di produzione.
Differenze di configurazione
È normale che gli ambienti abbiano indirizzi, credenziali e dimensioni diverse. L'importante è che queste differenze siano solo nella configurazione e non nel codice. Un'applicazione piena di condizioni del tipo «se siamo in produzione fai questo» si comporta in modo diverso proprio dove non è stata provata.
Differenze di dati
Un'applicazione testata con dieci righe di dati può rivelarsi lentissima con dieci milioni. Staging dovrebbe avere volumi e varietà di dati simili alla produzione. Copiare semplicemente il database di produzione in staging, però, porta dati personali reali in un ambiente meno protetto. Le alternative corrette sono dati anonimizzati o sintetici, generati in modo da riprodurre le caratteristiche di quelli veri senza contenere informazioni su persone reali.
Configurazione nell'ambiente: i principi twelve-factor
La metodologia twelve-factor app, pubblicata dagli sviluppatori della piattaforma Heroku, raccoglie dodici principi per applicazioni facili da distribuire. Alcuni riguardano direttamente gli ambienti:
| Principio | In pratica |
|---|---|
| Un solo codice, molti deploy | Lo stesso repository viene distribuito in tutti gli ambienti |
| Configurazione nell'ambiente | Indirizzi e credenziali arrivano da variabili d'ambiente, non dal codice |
| Servizi esterni come risorse collegate | Database e code si sostituiscono cambiando un indirizzo, senza modifiche al codice |
| Build, release, run separati | L'artefatto si costruisce una volta e si combina con la configurazione di ciascun ambiente |
| Parità tra sviluppo e produzione | Strumenti, versioni e tempi di rilascio il più possibile vicini |
| Log come flusso di eventi | L'applicazione scrive sullo standard output e l'ambiente decide dove raccoglierli |
Un test semplice per capire se la configurazione è separata bene: potresti rendere pubblico il codice in questo momento senza esporre alcuna credenziale? Se la risposta è no, qualcosa va spostato.
Ambienti temporanei
Un'evoluzione utile è l'ambiente effimero per ogni richiesta di modifica. Quando uno sviluppatore apre una pull request, la pipeline crea automaticamente un ambiente completo con quella versione, raggiungibile a un indirizzo dedicato. Chi revisiona può provarla davvero, non solo leggere il codice. Alla chiusura della richiesta l'ambiente viene distrutto.
Questo approccio richiede infrastruttura come codice e dati di test generabili automaticamente, ma elimina il collo di bottiglia di un unico staging conteso tra più persone.
Proteggere la produzione dagli altri ambienti
Separare gli ambienti significa anche impedire che si tocchino per errore:
- credenziali distinte per ogni ambiente, così che uno script di test non possa scrivere nel database reale;
- account o progetti cloud separati per produzione e non produzione, quando possibile;
- segnali visivi chiari, come un banner colorato nell'interfaccia di staging, per evitare di confondere le finestre;
- email e pagamenti disattivati o deviati negli ambienti di prova, per non inviare messaggi o addebiti a clienti reali.
Nel mio lavoro l'ultimo punto è quello che più spesso viene dimenticato: basta uno staging collegato al vero servizio di invio email per spedire una newsletter di prova a migliaia di persone.
In sintesi
- Ogni ambiente ha uno scopo: sviluppo rapido, test automatici, verifica in staging, produzione reale.
- Riduci al minimo le differenze di software, configurazione e dati tra gli ambienti.
- Le differenze devono stare nella configurazione, letta da variabili d'ambiente, mai nel codice.
- Usa dati anonimizzati o sintetici in staging, non copie dei dati personali di produzione.
- Separa credenziali e account e disattiva email e pagamenti reali negli ambienti di prova.
