Separa deploy da release
Rilasci una nuova versione e preghi? Sei in buona compagnia, lo fanno quasi tutti!
Perché succede? A parte perché forse non c’è una suite di test che ti trasmette la fiducia necessaria.
Ma a parte questo… La build va in produzione e in quel momento esatto diventa visibile a tutti gli utenti. Se qualcosa va storto, va storto per tutti. E quindi partono i soliti meccanismi di difesa: si rilascia poco frequentemente, si accumula… e si prova a rimandare il più possibile, spesso distruggendo la promessa della release a cadenza fissa o quel giorno stabilito, cosa deleteria per la fiducia da parte del business. Oppure, attenzione attenzione, i test manuali!
Perché? Cosa sta succedendo? Stai trattando due cose diverse come se fossero la stessa cosa. E non lo sono. Sono deployment e release.
Deploy ≠ Release
Il deployment è un’operazione tecnica. Prendi un artefatto e lo metti in un ambiente. Fine. È roba da pipeline, da infrastruttura e da automazione… ci siamo capiti.
La release è una decisione di business. Stai decidendo che una funzionalità diventa disponibile per gli utenti. È roba da product manager, da strategia.
Come si separano
La risposta breve è: feature flags.
Il codice va in produzione “spento”. È lì, nel server, pronto. Ma nessun utente lo sta esercitando o vedendo finché qualcuno non decide di accendere l’interruttore. In aggiunta, quel qualcuno non deve essere per forza uno sviluppatore. Può essere il product manager. Può essere il marketing. Può essere chiunque abbia il contesto di business per decidere quando è il momento giusto.
Nella pratica funziona così: nel codice avvolgi la nuova funzionalità in un blocco condizionale controllato da un flag. Se il flag è spento, il codice non viene eseguito. Se è acceso, gli utenti lo vedono.
Semplice? Concettualmente sì. Ma la libertà e l’agilità che ne conseguono sono enormi.
Cosa cambia quando li separi
Deploy senza ansia: il codice va in produzione ogni giorno, magari più volte al giorno. Tanto è spento.
Testi in produzione: non in un ambiente di staging che non assomiglia alla produzione. In produzione. Con dati reali, traffico reale, infrastruttura reale. Puoi abilitare la feature per il tuo team interno, validare tutto, e poi aprire gradualmente.
Rilascio graduale: apri al 5% degli utenti, anche se qui servono strumenti un po’ più sofisticati. Guardi le metriche… tutto ok? Sali al 20%. Poi al 50%. Poi al 100%. Se a un qualsiasi punto qualcosa non va, spegni il flag. Non fai rollback né un altro deployment. Spegni un interruttore con un tempo di recovery di secondi e non di minuti o ore.
Il business decide i tempi: il team di sviluppo esegue il deployment (magari in continuous). Il product manager rilascia quando il momento è giusto. Magari aspetta la conferenza. Magari aspetta che il supporto clienti sia formato. Il deploy non è più un vincolo per il business e il business non è più un vincolo per il deploy.
Non solo feature flags
Ci sono altre tecniche ma saranno argomento di altri messaggi.
Azioni
La prossima volta che fai un rilascio, chiediti:
- Deploy e release stanno avvenendo nello stesso momento?
- Se qualcosa va storto, la mia unica opzione è un rollback completo?
- Il business è costretto ad aspettare i miei tempi tecnici per rilasciare una feature?
Se hai risposto sì a una di queste domande, hai del lavoro da fare.
Sharing is caring
Se conosci qualcuno che potrebbe trovare utile ricevere e-mail per migliorare l’organizzazione dei team di sviluppo software, DevOps e software engineering in generale inoltragli questo post! Qui può iscriversi e cominciare a ricevere subito!