Il Deploy del Venerdì: La 'Piccola Modifica' che non rompe nulla

Narratore: Questo podcast è generato con l'ausilio di voci sintetiche. È venerdì pomeriggio. Ore sedici e trenta. Il team è in call per l'ultimo allineamento della settimana. Entra il Product Owner.

Product Owner: Ragazzi, ascoltate. Mi ha appena chiamato il commerciale. Il cliente Platinum ha notato che il colore del pulsante di conferma nel modulo ordini è leggermente diverso dall'ultimo brand book. È una modifica estetica, minima, letteralmente due righe di CSS. Dobbiamo metterlo online entro stasera, assolutamente, prima del weekend.

Junior Developer: Ma scusate, se è solo un cambiamento di colore, non possiamo semplicemente pianificarlo per lunedì mattina? In dieci minuti sarebbe fatto e non rischieremmo nulla l'ultimo giorno della settimana.

Product Owner: Junior, capisco la logica, ma il cliente Platinum ha un meeting di review lunedì alle nove. Se vedono il colore vecchio, penseranno che non abbiamo recepito il feedback. È una questione di percezione del valore, non di codice!

Junior Developer: Però, se è solo una questione di percezione, non potremmo inviare uno screenshot del nuovo colore al cliente e dirgli che il rilascio avverrà lunedì? Sarebbe più sicuro.

Product Owner: Uno screenshot? Junior, siamo nel ventunesimo secolo, non possiamo mandare immagini di cose che non esistono ancora in produzione! Il cliente vuole vedere il prodotto vivo!

Senior Developer: No.

Product Owner: Ma come no? È solo un colore! Due minuti di lavoro, un commit, un deploy e siamo a posto. Non rompiamo nulla, è solo l'interfaccia!

Senior Developer: Tre anni fa. Venerdì. Ore diciassette. 'Solo una virgola in un file di configurazione'. Abbiamo passato il sabato e la domenica a ricostruire il database di produzione da un backup che non funzionava. Non si deploya di venerdì.

Junior Developer: Scusate, posso chiedere una cosa? Ho guardato il modulo ordini e quel CSS è richiamato da un modulo legacy che gestisce anche le validazioni dei campi. Se tocchiamo quel file, non rischiamo di triggerare qualcosa nel vecchio motore di calcolo delle tasse?

Product Owner: Ma che c'entra il motore delle tasse con un pulsante? Junior, non complicare le cose. È un file CSS, non stai riscrivendo l'algoritmo di calcolo dell'IVA!

Senior Developer: Nel 2019 qualcuno ha pensato di mettere una variabile di stile dentro un helper di validazione per 'risparmiare righe'. Da allora, quel file è un campo minato. Tocchi un margine e salta il calcolo del lordo. Vedi? Il ragazzo ha capito.

Junior Developer: Quindi stiamo dicendo che un file di fogli di stile può influenzare il calcolo fiscale? Come è tecnicamente possibile?

Senior Developer: Non chiedere 'come'. Accetta solo che accade. È l'architettura a 'spirale'.

Narratore: Alla call si aggiunge il CTO.

Chief Technology Officer: Ciao a tutti. Ho sentito l'ultima parte. Ragazzi, guardiamo la cosa da una prospettiva più ampia. Non stiamo parlando di un rischio tecnico, ma di un'operazione di agilità reattiva. In un mercato così competitivo, il nostro time-to-market deve essere istantaneo. Allinearci al brand del cliente in tempo reale è un segnale di maturità DevOps.

Senior Developer: L'agilità reattiva non salva i dati se crasha il modulo tasse.

Chief Technology Officer: Esatto, ed è proprio per questo che dobbiamo fidarci dei nostri processi di CI/CD. Junior, Senior, fate l'upload della modifica. Se succede qualcosa, avremo un'opportunità di miglioramento immediata sui nostri test di regressione. Procediamo.

Junior Developer: Ok, ma se l'opportunità di miglioramento arriva perché il sito crasha durante l'ordine di un cliente Platinum, l'immagine del nostro time-to-market non ne risentirà?

Chief Technology Officer: Junior, l'innovazione richiede coraggio. Se aspettiamo che ogni singola dipendenza legacy sia mappata, non rilasceremmo più nulla. Dobbiamo accettare una certa dose di entropia per mantenere la nostra velocità competitiva. Fidati del processo.

Product Owner: Grazie! Grazie mille! Vedete? Basta un po' di spirito di squadra!

Narratore: Ore sedici e cinquanta. Il deploy è partito. Il team rimane in call, in un silenzio teso, a fissare la dashboard di monitoraggio.

Junior Developer: Il deploy è terminato. Stato: Success. Il pulsante è del colore giusto. Tutto sembra normale.

Senior Developer: Aspettate. Guardate i log del modulo tasse. Le query stanno rallentando. Non crasha, ma... sta iniziando a rispondere dopo otto secondi invece di duecento millisecondi.

Product Owner: Ma cosa significa? Il cliente vede il colore giusto, no? Questo rallentamento è critico?

Junior Developer: Non è critico ora, ma se aumenta il traffico nel weekend, il sistema potrebbe andare in timeout. Dovremmo fare il rollback subito.

Product Owner: Otto secondi! Ma è un'eternità! Il cliente Platinum chiuderà la pagina prima ancora di vedere il pulsante colorato! Dobbiamo fare qualcosa, ma senza tornare indietro!

Senior Developer: Beh, l'unico modo per non tornare indietro e risolvere il problema è riscrivere l'intero modulo tasse. Ci vogliono tre settimane. Vogliamo dirlo al cliente?

Chief Technology Officer: Un momento. Se facciamo il rollback adesso, il cliente vedrà il colore sbagliato di nuovo e ci chiederà perché abbiamo fatto un passo indietro. Sarebbe un segnale di instabilità. Invece, potremmo presentare questo comportamento come una fase di ottimizzazione asincrona.

Senior Developer: Ottimizzazione asincrona. Bellissimo. Altra parola per dire che abbiamo rotto tutto.

Chief Technology Officer: Esatto. Diciamo che è una feature sperimentale di caricamento progressivo. La monitoriamo nel weekend e lunedì mattina, con calma, implementiamo il fix definitivo. Nessuno si allarma, il cliente è felice del colore, e noi manteniamo l'immagine di un team che innova costantemente.

Junior Developer: Quindi... non facciamo il rollback?

Senior Developer: Benvenuto in azienda, Junior. Prepara il caffè, lunedì sarà una giornata lunga.