Rilasciare in produzione senza rischi poggia su quattro elementi: un ambiente di staging con dati realistici e anonimizzati, test automatici sui percorsi che fermerebbero l'azienda, feature flag che separano il rilascio del codice dall'attivazione della funzione, e migrazioni di database in due passaggi che rendono il ritorno alla versione precedente una questione di minuti.
Ci sono aziende dove il rilascio di una nuova versione è un evento: si avvisa il reparto, si aspetta il sabato, qualcuno resta reperibile. E ci sono aziende dove succede tre volte al giorno e nessuno se ne accorge. La differenza non è la bravura degli sviluppatori.
La differenza è quanto costa sbagliare. Se un errore in produzione significa mezz'ora di lavoro perso e un cliente irritato, si rilascia spesso. Se significa due giorni di dati da ricostruire a mano, si rilascia il meno possibile, e il software invecchia in fretta, perché ogni modifica si accumula con le altre in attesa della finestra buona.
Il venerdì pomeriggio come misura
La regola non scritta di non rilasciare il venerdì è un sintomo utile. Dice che il team non si fida della propria via di ritorno: se qualcosa si rompe alle sei di sera, nessuno vuole passare il sabato a capire cosa. Quando invece tornare alla versione precedente richiede cinque minuti e nessuna decisione difficile, il giorno della settimana smette di contare.
Quando ereditiamo un progetto, questa è una delle prime domande che facciamo. Non "quali test avete", ma "quanto ci vuole a tornare indietro". La risposta racconta più di qualsiasi documentazione.
Tre ambienti, non due
Molti progetti hanno il computer dello sviluppatore e la produzione. In mezzo, niente. Il risultato è che la prima volta in cui il codice incontra dati veri è anche la prima volta in cui li può danneggiare.
Serve un ambiente intermedio che somigli alla produzione nelle cose che contano: stessa versione di database, stesse variabili di configurazione, stesso comportamento delle integrazioni esterne, in modalità sandbox dove esiste. Non serve che sia potente. Serve che sia credibile. Venti anagrafiche finte non sono un ambiente di staging, sono una schermata di benvenuto.
Dati realistici, non dati reali. Copiare il database di produzione su staging risolve il problema del realismo e ne crea uno di privacy. Noi partiamo da un dump anonimizzato: nomi, email e telefoni sostituiti, volumi e casi strani conservati, perché sono proprio i casi strani a far cadere il codice.
La pipeline serve a dire di no
Una pipeline di continuous integration non è una questione di eleganza tecnica. È il posto dove un errore viene fermato da una macchina invece che da una persona sotto pressione. Test automatici, controllo dei tipi, linting, build: se uno di questi passi fallisce, il codice non arriva a staging e nessuno deve decidere se "per questa volta va bene così".
Il valore non sta nel novanta per cento di copertura. Sta nell'avere test sui percorsi che, se si rompono, fermano l'azienda: il login, la creazione di un ordine, il calcolo di un prezzo, l'emissione di una fattura. Dieci test su quelli valgono più di duecento sulle funzioni di utilità.
Chi ha già una pipeline spesso ha il problema opposto: test lenti e instabili che falliscono a caso, che il team ha imparato a ignorare rilanciando la build. Un test a cui nessuno crede è peggio di un test che non esiste, perché occupa il posto di quello che servirebbe.
Rilasciare e attivare sono due cose diverse
Il momento più teso di un rilascio è quando codice nuovo e funzione nuova arrivano insieme. Separarli cambia la giornata. Con un feature flag il codice va in produzione spento, si accende per due utenti interni, poi per un reparto, poi per tutti. Se qualcosa non torna, si spegne l'interruttore senza toccare il deploy.
Vale soprattutto per i portali usati da clienti o fornitori esterni, dove non puoi permetterti di scoprire un problema dai ticket. Lo abbiamo usato molto per cambi di interfaccia su gestionali interni: gli utenti che vogliono provare la versione nuova la attivano, gli altri continuano a lavorare come prima, e il rientro è una casella da togliere.
Un'avvertenza: i flag vanno rimossi. Un progetto con quaranta interruttori vecchi di due anni ha barattato un problema di rilasci con un problema di combinazioni che nessuna suite di test copre.
Tornare indietro in cinque minuti
Il rollback del codice è la parte facile: si ripubblica la versione precedente. La parte difficile è il database. Una migrazione che rinomina una colonna o ne elimina una rende il ritorno impossibile senza perdere dati.
La tecnica che usiamo è banale e funziona: le modifiche allo schema vanno in due tempi. Prima si aggiunge la colonna nuova e si scrive su entrambe, mentre il codice legge ancora dalla vecchia. Poi, quando la versione nuova è stabile da qualche giorno, si smette di scrivere sulla vecchia e la si elimina. Tra i due passaggi si può tornare indietro in qualsiasi momento senza pensarci.
Sapere che è andata bene
Un deploy che riesce tecnicamente e rompe qualcosa in silenzio è il caso peggiore, perché il team lo scopre giorni dopo da una segnalazione. Bastano tre cose, e costano meno di quanto si teme: log centralizzati e ricercabili, un raccoglitore di errori che avvisa sul canale del team quando compare un'eccezione nuova, e un paio di controlli sulle metriche che contano per quel software, per esempio gli ordini creati nell'ultima ora o il tempo di risposta delle pagine più usate.
Chi ha la sua unica visibilità nei log dell'hosting, scaricati a mano quando qualcuno si lamenta, sta pagando quella mancanza in ore di diagnosi. Con una nota: i log servono a poco se nessuno li guarda quando le cose vanno bene, perché non si riconosce l'anomalia senza sapere com'è fatto il normale.
Nessuno di questi pezzi è costoso da introdurre. Sono costosi da introdurre tutti insieme e di corsa, dopo un incidente. Se oggi rilasciare vi mette ansia, l'ordine è chiaro: prima una via di ritorno affidabile, poi un ambiente di staging credibile, poi i test sui percorsi critici. Nei progetti software su misura che seguiamo, quella sequenza non si è mai rivelata sbagliata.
