Pianificare le strategie di rollback prima del primo deployment fallito.

Cosa è necessario predisporre per un rollback prima del primo deployment fallito?

Devono essere disponibili un ultimo stato valido immutabile, un percorso di rollback documentato e un ruolo decisionale. Le modifiche ai dati devono rimanere retrocompatibili o disporre di un proprio piano di ripristino.

Ultimo stato valido

• Ultimo stato valido Codice, artefatti e configurazione necessari sono chiaramente identificati e disponibili.

• Limite decisionale L'impatto del guasto e il tempo di risposta determinano in anticipo quando si verifica un rollback.

• Compatibilità dei dati L'applicazione legacy può leggere in modo sicuro lo stato corrente dei dati oppure questo viene ripristinato in modo controllato.

Limite decisionale

1. Fornire in modo immutabile l'ultimo stato valido, la configurazione e le dipendenze.

2. Definire classi di errore, soglie, responsabili delle decisioni e canali di comunicazione.

3. Testare il rollback e il riavvio con dati rappresentativi e autorizzazioni reali.

Compatibilità dei dati

Caso di controllo: "Percorso di rollback non testato"

Una nuova versione genera errori nel percorso di query centrale. La soglia definita attiva il passaggio all'artefatto precedente salvato; una colonna del database precedentemente estesa rimane compatibile e non necessita di essere ripristinata in tempi ristretti.

Rollback non testato

• Rollback non testato – L'incidente non dispone di autorizzazioni, comandi o di un artefatto funzionante perché il percorso di rollback non è mai stato testato in condizioni realistiche.

• Trappola dello schema – Il codice obsoleto viene avviato ma corrompe i dati già migrati o si aspetta elementi dello schema che sono stati rimossi.

• Decisione ritardata – Senza una soglia, il danno si accumula durante un lungo processo diagnostico prima ancora che venga presa una decisione sul rollback.

Domande correlate e prossimi passi

Note di rilascio per modifiche tecniche e aziendali risponde alla successiva domanda pratica: quali informazioni rendono le note di rilascio utili sia per gli stakeholder aziendali che per quelli tecnici?

Distribuzione di risorse statiche con tempi di esecuzione lunghi e parametri di versione prosegue su questa linea di pensiero con un'altra domanda: come si combinano tempi di esecuzione lunghi della cache con modifiche immediatamente visibili alle risorse statiche?

Se vuoi implementare concretamente la "pianificazione di un rollback prima che si verifichi l'errore", puoi andare a Sistemi web robusti a cui fare riferimento. Lì, l'attenzione si concentra su "Rilascio, artefatto e restauro" e "Ultimo stato buono".

Conclusione: Pianificare un rollback prima di un errore

Un rollback è una procedura operativa predefinita. Artefatti, dati e autorizzazioni devono funzionare insieme ed essere testati in condizioni realistiche.

Fonti e ulteriori informazioni

Le fonti primarie definiscono il quadro tecnico per "pianificare un rollback prima di un errore".

• Specifica SLSA 1.1La specifica primaria definisce la prova di origine e i requisiti per artefatti di build affidabili e tracciabili.

• Distribuzioni e ambienti – Documentazione GitHubLa documentazione del fornitore specifica le autorizzazioni ambientali, le regole di protezione e gli stati di distribuzione controllati.