Rilasciare dovrebbe essere noioso.
Se un rilascio richiede una persona precisa, una serata tranquilla e il fiato sospeso, il vostro team rilascia meno spesso del dovuto, e ogni rilascio è più rischioso perché contiene più cambiamenti.
Costruiamo pipeline che testano e rilasciano il vostro codice in automatico, con la possibilità di tornare indietro in pochi secondi. I team che rilasciano facilmente rilasciano spesso, e i rilasci piccoli sono molto più sicuri di quelli grandi. Partiamo osservando un rilascio vero, così il lavoro si basa su ciò che succede davvero.
Aggiornato novembre 2026
I rilasci dolorosi rendono i rilasci più grandi, e sono i rilasci grandi a rompere le cose.
È un circolo. Rilasciare è stressante, quindi succede di rado. I rilasci rari accumulano più cambiamenti, il che rende ognuno più rischioso, il che lo rende più stressante.
L’automazione rompe il circolo dall’altra parte. Quando rilasciare richiede pochi minuti e tornare indietro pochi secondi, i rilasci diventano più piccoli e più frequenti, e i rilasci piccoli sono la cosa più importante che possiate fare per l’affidabilità.
Non è un lavoro enorme. La maggior parte dei team è più vicina di quanto pensi a una pipeline che esegue i test, rilascia a ogni merge e si può annullare all’istante.
Che cosa impostiamo.
Test a ogni modifica
Eseguiti in automatico prima di ogni merge, così il codice rotto non arriva al ramo principale.
Rilascio al merge
Unito significa rilasciato. Nessun rito separato, nessuna persona da rincorrere.
Ritorno indietro in pochi secondi
È ciò che rende sicuro rilasciare. Senza, tutti fanno bene a essere nervosi.
Un ambiente di prova
Che somigli davvero alla produzione, invece di una versione che se n’è allontanata otto mesi fa.
Migrazioni del database
La parte che fa inciampare quasi tutte le pipeline. Applicate in modo sicuro, reversibili dove possibile.
Segreti fuori dal codice
Gestiti come si deve. Le credenziali in un repository sono un problema comune e serio.
Ambienti di anteprima
Ogni pull request ha un indirizzo vivo, così la revisione si fa guardando.
Avvisi quando un rilascio fallisce
Al team, subito, invece di scoprirlo la mattina dopo.
Che cosa cambia quando i rilasci sono automatici.
La seconda colonna non è un’aspirazione: è ciò che produce una pipeline normale.
| Rilasci manuali | Automatici | |
|---|---|---|
| Quanto spesso rilasciate | Una volta a settimana o meno | Ogni giorno, o a ogni merge |
| Dimensione di ogni rilascio | Grande: settimane di modifiche | Piccola: una modifica |
| Quando qualcosa si rompe | Quale delle quaranta modifiche? | Quella appena rilasciata |
| Tornare indietro | A mano, sotto pressione | Pochi secondi, un comando |
| Chi può rilasciare | Una o due persone | Chiunque nel team |
| Rilasciare di venerdì | Nessuno osa | Niente di speciale |
Come lavoriamo noi.
I nostri clienti vedono software funzionante ogni due settimane: funziona solo se rilasciare è banale.
La prima cosa che costruiamo, perché rende sicuro tentare tutto il resto.
Un link per ogni pull request, così la revisione è guardare e non immaginare.
Quando farlo.
Può rilasciare una persona sola
Un collo di bottiglia e un rischio. E anche ingiusto per quella persona.
I rilasci sono eventi
Se rilasciare richiede un appuntamento in calendario, succede troppo di rado.
Non riuscite a tornare indietro in fretta
La cosa di maggior valore da sistemare. Tutto il resto diventa più facile dopo.
Non fa per voi se il codice cambia due volte l’anno
Per un sistema stabile che si aggiorna di rado, una procedura manuale scritta bene può bastare. Ve lo diciamo invece di costruire una pipeline che nessuno userà.
Come lavoriamo.
Osserviamo un rilascio vero
Qualunque cosa succeda oggi, compresi i passaggi manuali che nessuno ha mai scritto.
Costruiamo prima il ritorno indietro
Prima di tutto il resto. È ciò che rende sicuro provare ogni cambiamento successivo.
Automatizziamo i test
Eseguiti a ogni modifica, bloccano il merge quando falliscono.
Automatizziamo il rilascio
Prima l’ambiente di prova, poi la produzione, quando la prova è stata noiosa per un po’.
Gestiamo le migrazioni
La parte che più spesso rompe le pipeline. In modo sicuro, e reversibile dove si può.
Consegniamo
Documentato, così è del vostro team e non dipende da noi.
Automazione CI/CD
6 domande con risposta. Ne avete un’altra? Scriveteci.
Di solito meno di quanto si pensi. La variabile non è la pipeline: è quanto rito manuale si è accumulato attorno al vostro rilascio attuale, e se le migrazioni del database sono semplici. Osserviamo prima un rilascio vero, così la stima si basa su ciò che succede davvero, e la mettiamo per iscritto.
Sette categorie. Quarantacinque servizi.
Raccontateci il progetto, com’è davvero.
Scriveteci cosa vi serve e dove siete bloccati. Vi rispondiamo entro un giorno lavorativo con domande vere, e se il progetto dovrebbe essere più piccolo di come lo immaginate ve lo diremo.