Cos'è il progressive delivery? Guida per i team di sviluppo

Cos'è il progressive delivery? È un modo di rilasciare il software in cui una modifica arriva in produzione per passi piccoli e controllati, e ogni passo viene verificato con metriche reali prima che parta il successivo. Se i numeri peggiorano, il rilascio si ferma o torna indietro da solo. Così non si scommette tutta la base utenti su un unico deploy.

Ecco una situazione che probabilmente conosce. Una pull request viene approvata, la CI è verde, il deploy parte di martedì pomeriggio e venti minuti dopo qualcuno chiede in chat perché la latenza del checkout sia raddoppiata. Il progressive delivery serve ad accorciare quella conversazione e a far succedere il problema al 5% del traffico invece che al 100%.

Che cosa cambia davvero con il progressive delivery?

Il continuous delivery risponde a una domanda: possiamo rilasciare questa modifica in produzione in sicurezza? Il progressive delivery ne aggiunge una seconda: chi la vede per primo, e che cosa ci dice di fermarci?

La mossa centrale è separare il deploy dal rilascio. Fare il deploy significa che il nuovo codice gira sui server. Rilasciare significa che gli utenti ne sono esposti. Una volta separate le due cose, si può fare il deploy alle 14 di un mercoledì e decidere con calma quando, e verso quale pubblico, esporre la novità, avendo sempre una via di ritorno.

Molte fonti concordano su tre elementi: lo spostamento graduale del traffico (canary), gli ambienti paralleli (blue-green) e i feature flag. Non sono alternative tra loro. I team maturi li usano a livelli diversi.

Canary release: quanto traffico, e chi decide?

Una canary release manda una piccola quota di traffico alla nuova versione, per esempio il 5%, mentre il resto resta sulla versione precedente. Se il tasso di errore, la latenza e la saturazione restano nelle soglie, la quota cresce: 5%, 25%, 50%, 100%. Se non restano, il traffico torna indietro.

Il punto delicato è che le suddivisioni fini richiedono qualcosa che sappia dividere il traffico. La documentazione di Argo Rollouts spiega che le percentuali precise di canary richiedono un gestore del traffico, come un service mesh o un ingress controller. Senza, si ottiene un controllo grossolano basato sul numero di repliche, quindi il "5%" può voler dire davvero "un pod su venti".

Ecco come appare un canary a fasi in un manifest di Argo Rollouts. È volutamente breve.

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 10m }   # osservare le dashboard o eseguire l'analisi
      - setWeight: 25
      - pause: { duration: 10m }
      - setWeight: 100

Salti il canary se il suo servizio riceve così poco traffico che il 5% equivale a qualche richiesta all'ora. Aspetterà un segnale all'infinito, oppure leggerà il rumore come se fosse sicurezza. Per i servizi a basso traffico, un feature flag rivolto agli utenti interni è un primo cancello migliore.

Blue-green deployment: quando vale la pena avere un secondo ambiente completo?

Il blue-green mantiene due ambienti di produzione completi. Blue serve gli utenti. Green riceve la nuova versione e viene testato mentre è inattivo. Quando il test è soddisfacente, il traffico passa dall'uno all'altro.

Secondo la documentazione di Argo Rollouts, il passaggio avviene tutto in una volta: la vecchia versione mantiene tutto il traffico di produzione finché la nuova non è verificata, poi la divisione passa dallo 0% al 100%. È il suo punto di forza e il suo limite. Il rollback è un singolo scambio all'indietro, quindi è rapido. Ma il test avviene prima che arrivino utenti reali, e il costo è il doppio dell'infrastruttura mentre entrambi i lati sono attivi.

Ne vale la pena per un servizio con stato o ad alto rischio, dove un rilascio parziale creerebbe confusione, per esempio un flusso di pagamento in cui due versioni non devono mai gestire insieme la stessa richiesta. Lo eviti se la migrazione del database non può girare con entrambe le versioni contemporaneamente, perché allora il "rollback istantaneo" è una finzione.

Dove entrano i feature flag?

Canary e blue-green lavorano a livello di infrastruttura. I feature flag lavorano dentro l'applicazione. Un flag racchiude un percorso di codice in una condizione che si può modificare a runtime, senza un nuovo deploy.

Questo rende i flag lo strumento più granulare a disposizione. Si può esporre una funzione prima ai dipendenti, poi all'1% degli account, poi a un segmento di clienti, e spegnerla in pochi secondi se si comporta male. Alcuni team considerano i flag solo una tecnica tra le altre, altri li vedono come il fattore abilitante dell'intero approccio. In pratica la seconda visione regge: appena si vuole rilasciare per pubblico invece che per server, serve un flag.

I flag hanno però un costo. Ogni flag è un ramo che i test devono coprire e un ticket di pulizia che qualcuno deve chiudere. Se vuole la versione più lunga, abbiamo trattato meccanismi e debito in cos'è un feature flag. Consideri ogni flag di breve durata come impostazione predefinita, con un responsabile e una data di rimozione.

Strumenti come LaunchDarkly e Statsig vendono il livello di gestione: regole di targeting, log di audit, rilasci graduali in percentuale ed esperimenti.

Che cosa rende un rilascio progressivo e non solo lento?

L'automazione. Un rilascio che si ferma dieci minuti mentre una persona guarda una dashboard è un deploy lento. Diventa progressive delivery quando una macchina controlla le metriche e decide.

Lo schema è lo stesso ovunque:

1. Definire i segnali prima del rilascio: tasso di errore, latenza p95, una metrica di business come il completamento del checkout.

2. Definire le soglie di "stop", scritte in configurazione e non nella testa di qualcuno.

3. Lasciare che il controller promuova, trattenga o riporti indietro la versione in base a questi segnali.

Argo Rollouts si integra con i provider di metriche, quindi un rollout può essere promosso o interrotto automaticamente a seconda che i controlli passino. Una delle fonti che abbiamo esaminato lo dice senza giri di parole: il progressive delivery senza rollback automatico è solo un deploy lento. Siamo d'accordo.

Quali metriche devono governare un rilascio?

Ne tenga poche. Tre o quattro segnali di cui si fida già battono venti che non ha mai fatto scattare un allarme.

Un insieme di partenza utilizzabile: tasso di errori 5xx HTTP della canary rispetto alla baseline, latenza p95 della canary rispetto alla baseline, saturazione (CPU, memoria, profondità delle code) e una metrica di prodotto. Confronti canary e baseline nello stesso momento, non la canary con "la settimana scorsa", perché i pattern di traffico cambiano.

Qui lo stack di osservabilità smette di essere un optional. Se non riesce a suddividere le metriche per versione o per variante del flag, non può distinguere la canary dalla baseline, e l'intero approccio crolla. Il nostro primer su cos'è l'osservabilità spiega come arrivarci.

Come si collega il progressive delivery al trunk-based development?

Le due cose si combinano bene. Il trunk-based development mantiene i rami brevi e integra spesso piccole modifiche. Il rischio è che lavoro incompleto o non testato arrivi sul main più spesso. Il progressive delivery rende tutto questo sicuro: il codice entra nel trunk, viene rilasciato nascosto dietro un flag e poi esposto gradualmente.

Lotti piccoli ed esposizione graduale rendono anche il debugging meno costoso. Quando una canary fallisce, la lista dei sospetti è una modifica, non quaranta. Chi ha fatto un bisect su una settimana di commit uniti alle 23 sa quanto vale.

Qual è un primo passo realistico per un team da 10 a 30 ingegneri?

Non inizi installando un service mesh. Parta dallo strumento più piccolo che le dia un pulsante di stop.

• Settimana 1: metta una funzione rischiosa dietro un flag e la rilasci prima al suo team.

• Settimana 2: aggiunga dashboard per versione con tasso di errore e latenza. Se i suoi strumenti non sanno suddividere per versione, sistemi prima questo.

• Settimana 3 e oltre: sposti un servizio stateless su un controller di canary con due o tre passi e un abort automatico sul tasso di errore.

Misuri in ore, non in una "sensazione di sicurezza". Conti quanti incidenti sono rimasti confinati a una piccola fetta di utenti e quanto ha richiesto il rollback. Questi due numeri diranno se l'approccio funziona per il suo team.

Dove si rompono di solito i rilasci progressivi?

In tre punti, e nessuno dei tre è il controller.

Migrazioni del database. Una canary significa che due versioni del codice colpiscono lo stesso database nello stesso momento. Se la versione N+1 elimina o rinomina una colonna che la versione N legge ancora, la canary abbatte la baseline. La soluzione noiosa ma affidabile è expand and contract: aggiungere prima la nuova colonna, rilasciare codice che scrive in entrambe, fare il backfill, spostare le letture e solo più tardi rimuovere quella vecchia.

Sessioni appiccicose e cache. Se un utente rimbalza tra vecchia e nuova versione a ogni richiesta, nascono bug che nessuno riesce a riprodurre. Fissi gli utenti a una variante per tutta la durata del rollout, tramite cookie, ID account o valutazione del flag.

Metriche in ritardo. Una metrica di conversione che si aggiorna ogni ora non può governare un passo di canary di dieci minuti. Durante il rollout usi segnali rapidi (errori, latenza) e controlli la metrica di business lenta prima di passare dal 50% al 100%.

Come si tiene traccia di ciò che è attivo nel repository?

Il progressive delivery distribuisce un rilascio tra file di configurazione, definizioni dei flag, manifest di rollout e dashboard. Dopo qualche mese, la domanda "quale flag protegge il nuovo percorso di fatturazione, e chi ne è responsabile?" diventa la solita routine: grep, blame, poi chiedere a qualcuno.

È un problema di lettura del codice, più che di strumenti. Cercare nel repository per chiave del flag e seguire ogni riferimento fino al punto di chiamata è il modo più rapido per trovare flag morti e rollout a metà. Uno strumento che risponde a "dove viene valutato questo flag e che cosa succede quando è spento?" partendo dal codice reale fa risparmiare più tempo di un'altra dashboard.

Che cosa lascerei perdere

Eviti il blue-green per tutto se la bolletta dell'infrastruttura è già un tema di discussione. Eviti le canary sui servizi con quasi nessun traffico. Eviti qualunque strumento di rollout che nessuno nel team sa far funzionare alle 3 di notte.

Il vero problema non è la strategia che sceglie. È il divario tra spedire codice e sapere che cosa fa in produzione. Il progressive delivery riduce quel divario una fetta di traffico alla volta, e la prima fetta è quella che conta: la renda piccola, la renda osservabile e le dia un interruttore di spegnimento.