Rilascio di una versione

Le fasi

1. 1

   Congelamento

   settimana 1
   • Contenuto della versione e calendario del rilascio
   • Modifiche ancora aperte: chiuse o rinviateDopo «Contenuto della versione e calendario del rilascio».
   • Dipendenze aggiornate e vulnerabilità note verificateDopo «Contenuto della versione e calendario del rilascio».
   • Migrazioni del database reversibili e compatibili con la versione precedenteDopo «Contenuto della versione e calendario del rilascio».
   • Ramo di rilascio e numero di versioneDopo «Modifiche ancora aperte: chiuse o rinviate», «Dipendenze aggiornate e vulnerabilità note verificate», «Migrazioni del database reversibili e compatibili con la versione precedente».
   • Funzioni congelateDopo «Ramo di rilascio e numero di versione».
2. 2

   Test

   settimane 1–3
   • Prima versione candidata in collaudoDopo «Funzioni congelate».
   • Test delle modifiche nuove sui criteri di accettazioneDopo «Prima versione candidata in collaudo».
   • Test di regressioneDopo «Prima versione candidata in collaudo».
   • Prova delle migrazioni su una copia dei dati di produzioneDopo «Prima versione candidata in collaudo».
   • Prova di carico sui percorsi principaliDopo «Prova delle migrazioni su una copia dei dati di produzione».
   • Analisi di sicurezza del codice e dei componentiDopo «Prima versione candidata in collaudo».
   • Correzione dei difetti bloccantiDopo «Prima versione candidata in collaudo».
   • Versione candidata finale in pre-produzioneDopo «Correzione dei difetti bloccanti», «Test di regressione», «Test delle modifiche nuove sui criteri di accettazione», «Prova di carico sui percorsi principali», «Analisi di sicurezza del codice e dei componenti».
   • Test superati, nessun difetto bloccante apertoDopo «Versione candidata finale in pre-produzione».
3. 3

   Documentazione

   settimane 2–3
   • Documentazione delle API e preavviso a chi le integraDopo «Funzioni congelate».
   • Manuale e aiuto in linea aggiornatiDopo «Funzioni congelate».
   • Note di rilascio per i clientiDopo «Test delle modifiche nuove sui criteri di accettazione».
   • Registro tecnico delle modificheDopo «Test delle modifiche nuove sui criteri di accettazione».
   • L'assistenza prova le novità e i problemi notiDopo «Note di rilascio per i clienti», «Manuale e aiuto in linea aggiornati».
   • Documentazione prontaDopo «L'assistenza prova le novità e i problemi noti», «Registro tecnico delle modifiche», «Documentazione delle API e preavviso a chi le integra».
4. 4

   Rilascio

   settimana 3
   • Avviso ai clienti della finestra di rilascioDopo «Funzioni congelate».
   • Riunione di go/no-goDopo «Test superati, nessun difetto bloccante aperto», «Documentazione pronta».
   • Rilascio in produzione4 sottotaskDopo «Riunione di go/no-go», «Avviso ai clienti della finestra di rilascio».
   • Versione in produzioneDopo «Rilascio in produzione».
5. 5

   Dopo il rilascio

   settimana 4
   • Errori, prestazioni e segnalazioni dei primi giorniDopo «Versione in produzione».
   • Annuncio della versione ai clientiDopo «Versione in produzione».
   • Correzioni urgenti, se servonoDopo «Versione in produzione».
   • Correzioni riportate sul ramo principale e ramo di rilascio chiusoDopo «Correzioni urgenti, se servono».
   • Retrospettiva del rilascioDopo «Errori, prestazioni e segnalazioni dei primi giorni», «Annuncio della versione ai clienti», «Correzioni urgenti, se servono».
   • Rilascio chiusoDopo «Retrospettiva del rilascio», «Correzioni riportate sul ramo principale e ramo di rilascio chiuso».

I rischi tipici

• Modifiche entrate dopo il congelamento

  Alto · 12

  «È solo una piccola cosa»: una modifica entra a test iniziati e porta un difetto che nessuno ha provato.

  Evitare: Sul ramo di rilascio entrano solo correzioni di difetti bloccanti; un'eccezione la decide chi decide al go/no-go, per iscritto.

• Difetto bloccante scoperto a ridosso del rilascio

  Alto · 12

  La regressione trova un problema serio il giorno prima: o si rimanda, o si rilascia con un rischio.

  Mitigare: Regressione automatica dal primo giorno della candidata; i percorsi principali si provano per primi; un giorno di margine fra i test e il go/no-go.

• Migrazione del database lenta o irreversibile

  Alto · 10

  La migrazione dura più della finestra o non si può annullare: il servizio resta fermo, o tornare indietro fa perdere dati.

  Mitigare: Migrazioni compatibili con la versione precedente; prova cronometrata su una copia della produzione; copia di sicurezza subito prima del rilascio.

• Rilascio fallito senza ritorno indietro

  Alto · 10

  La versione nuova non parte in produzione, e quella vecchia non si può più rimettere.

  Mitigare: Piano di ritorno indietro scritto e provato in pre-produzione; il criterio per decidere il ritorno, con un tempo massimo, fissato prima della finestra.

• Assistenza impreparata alle domande dei clienti

  Medio · 6

  I clienti chiamano per una funzione cambiata e l'assistenza la scopre da loro.

  Mitigare: L'assistenza prova le novità prima del rilascio; problemi noti e risposte pronte nella documentazione interna.

• Vulnerabilità nota in un componente della versione

  Alto · 12

  Una dipendenza con una vulnerabilità pubblicata arriva in produzione insieme alla versione.

  Mitigare: Analisi dei componenti sulla prima candidata e sulla finale; una vulnerabilità grave blocca il rilascio come un difetto. Per un prodotto con elementi digitali venduto nell'Unione, il Cyber Resilience Act (Reg. UE 2024/2847) chiede dall'11 settembre 2026 di notificare le vulnerabilità sfruttate attivamente.

Le pagine dei documenti

• Criteri di go/no-go
• Note di rilascio
• Piano di ritorno indietro