Proteggere le modifiche al database insieme alle modifiche al codice.
Le modifiche allo schema vengono versionate, verificate automaticamente e scaglionate per garantire la compatibilità tra le vecchie e le nuove versioni dell'applicazione durante il rilascio.
In questo articolo si discute della "Protezione congiunta di modifiche al database e al codice" dal punto di vista di "rilascio, artefatto e ripristino". Per gli sviluppatori e i responsabili di progetto tecnici, la "compatibilità futura" e l'"accettazione atomica" sono particolarmente importanti.
Pubblicato: 3 minuti di lettura · Autore: Sebastian Geier
Come è possibile implementare le migrazioni di database senza un rischioso accoppiamento con una modifica del codice?
I nuovi campi o le nuove strutture vengono introdotti prima del codice che li utilizza. I dati vengono trasferiti in modo controllato; i vecchi lettori rimangono funzionanti durante la transizione e i campi deprecati scompaiono solo dopo averne dimostrato il mancato utilizzo.
Assunzione atomica
Assunzione atomica – Un'implementazione parziale rende il codice e lo schema incompatibili e causa errori nelle versioni parallele.
Migrazione bloccante – Una modifica importante ritarda inaspettatamente l'accesso alla produzione e causa code o timeout sotto carico.
Degradazione prematura Il codice di rollback richiede un campo che è già stato eliminato e non può essere riavviato in modo affidabile dopo una migrazione distruttiva.
Degradazione tardiva
Segnale di controllo
Segnale 1
Migrazioni con tempo di blocco, tasso di errore e ripresa dell'avanzamento.
Segnale di controllo
Segnale 2
Accesso ai vecchi campi dopo il passaggio al nuovo percorso del codice.
Compatibilità futura
Criterio di test
Compatibilità futura
Il vecchio codice tollera la struttura estesa durante il rilascio scaglionato.
Criterio di test
Migrazione osservabile
Avanzamento, errori e riavvii del trasferimento dati sono misurabili.
Degradazione tardiva – La disattivazione avviene solo quando tutti i lettori e i percorsi di fallback non richiedono più la vecchia parte.
Esempio pratico: "Assunzione atomica"
Inizialmente viene aggiunta e popolata in parallelo una nuova colonna normalizzata. Le nuove versioni dell'applicazione leggono preferenzialmente il nuovo valore, ma possono utilizzare il fallback; solo quando non è più visibile alcun lettore della vecchia versione, la manutenzione dei duplicati termina e il vecchio campo viene rimosso.
Migrazione osservabile
Le modifiche allo schema e al codice vengono suddivise in fasi di estensione compatibile, passaggio alla nuova versione e disattivazione.
Le migrazioni vengono sottoposte a pre-verifica, registrazione dell'avanzamento e riavvio sicuro.
La vecchia struttura viene rimossa solo dopo la verifica dell'utilizzo e la scadenza della finestra di fallback.
Quali domande sulla "Protezione congiunta del database e delle modifiche al codice" attivano ulteriori verifiche?
Una domanda di approfondimento pertinente con relativa risposta Verifica delle distribuzioni con controlli di integrità anziché solo con codici di uscita"Quali controlli di integrità mostrano effettivamente se un'implementazione è operativa? "
Un secondo link per "Proteggere insieme database e modifiche al codice" conduce a: Pianificare le modifiche DNS durante le migrazioni senza tempi di inattività non necessari.Questo post rimane incentrato sulla domanda: "Come si pianificano le modifiche DNS quando le risposte memorizzate nella cache non scompaiono immediatamente? "
Se si desidera implementare concretamente "Proteggere insieme database e modifiche al codice", è possibile fare riferimento a: Sistemi web robusti Questo si concentra su "Rilascio, artefatti e ripristino" e "Compatibilità futura".
Conclusione: Proteggere insieme database e modifiche al codice
Le modifiche sicure ai dati si sovrappongono intenzionalmente alle applicazioni vecchie e nuove. Disaccoppiare le modifiche nel tempo rende gestibili il rollout e il rollback.
Fonti e ulteriori informazioni
Le seguenti fonti documentano le linee guida tecniche e metodologiche utilizzate per "Proteggere congiuntamente database e modifiche al codice".
Distribuzioni e ambienti – Documentazione GitHubLa documentazione del fornitore specifica le autorizzazioni ambientali, le regole di protezione e gli stati di distribuzione controllati.
Specifica SLSA 1.1La specifica primaria definisce la prova di origine e i requisiti per artefatti di build affidabili e tracciabili.
Tesi chiave
Le modifiche allo schema di estensione vengono eseguite prima del nuovo codice, i dati vengono migrati in modo controllato e i vecchi campi vengono rimossi solo in un secondo momento. Ogni migrazione include test preliminari, backup, monitoraggio in fase di esecuzione e un percorso di ripristino realistico.
Cosa non riguarda
Una migrazione del database non deve richiedere che il vecchio e il nuovo codice vengano modificati esattamente in simultanea.
Di cosa si tratta
Le fasi di estensione, migrazione e rimozione vengono eseguite separatamente e si sovrappongono in modo compatibile.
Git, distribuzione e controllo qualità
Note di rilascio per modifiche tecniche e aziendali
Come verifica separata per "Proteggere congiuntamente database e modifiche al codice", la domanda dovrebbe essere: quali informazioni forniscono le note di rilascio che siano utili sia per il lato commerciale che per quello tecnico?
Git, distribuzione e controllo qualità
Collegamento delle release di staging con responsabilità chiare
Integrazione di "Proteggere congiuntamente database e modifiche al codice" con una decisione separata: chi verifica cosa prima che una versione di staging possa essere spostata in produzione?
Panoramica degli Insight
Tutti gli Insight di VELUNO in sintesi
Ulteriori analisi sui sistemi web, la visibilità digitale e modelli di lavoro robusti.
Migrazione osservabile: Prossimo controllo incrociato
La prossima modifica dello schema sarà pianificata in tre release separate. Questo rivelerà fin da subito quali lettori e percorsi dati devono rimanere retrocompatibili.