Il falso senso di sicurezza
Molti team dichiarano di avere una pipeline standardizzata perché usano gli stessi YAML o gli stessi stage. Ma staging e produzione divergono comunque quando cambiano variabili di environment, secret, approvazioni manuali, service connection o artifact promossi in modo non coerente.
Segnali di drift
- Deploy riuscito in staging ma non in produzione — spesso indica differenze esterne al codice, non un difetto dell'applicazione.
- Step manuali non tracciati — hotfix, transform o override fatti a mano rompono la riproducibilità della release.
- Artifact diversi per ambiente — build multiple dello stesso commit o packaging differente rendono impossibile il confronto reale.
- Secret e variabili non governati — naming incoerente o valori divergenti tra ambienti generano errori intermittenti difficili da spiegare.
Cosa controllare
Serve verificare che lo stesso artifact passi davvero tra gli ambienti, che le differenze di configurazione siano volute e versionate, e che approval, gate e manual intervention siano minimizzati o almeno esplicitati. In parallelo va controllata la gestione dei secret e la coerenza delle service connection.
Esito utile
Una review ben fatta produce pipeline più prevedibili, meno incidenti da differenze ambientali e tempi di rollback molto più rapidi. L'obiettivo non è avere più automazione in astratto, ma ridurre il numero di variabili nascoste che separano staging da produzione.