Come gestire modifiche impreviste dello schema al database di produzione

Se posso essere così sfacciato;)

Il problema non riguarda le modifiche impreviste dello schema alla produzione, anche se questo è certamente un sintomo.

In realtà è:

"Perché non diversi membri della mia organizzazione comunicano sulle modifiche che si influenzano a vicenda"

Una volta visualizzato in questo modo, ha più senso guardare:

• processi correnti di modifiche al codice e al database
• processo corrente per la notifica agli altri
• processo corrente per l'esecuzione di test per tali modifiche
• i metodi correnti usati per comunicare (email, IM, Project tracker, ecc.)

ecc.

La risposta breve: registrala, forse avvisa l'utente e forse continua l'esecuzione della tua applicazione.

Le modifiche avvengono continuamente. In produzione. Senza preavviso. Spesso per errore.

Anche con le politiche di controllo dei cambiamenti scolpite nella pietra, gli errori accadono. Un DBA che ottimizza una query rilascia una tabella. Uno sviluppatore con un accesso eccessivo rimuove accidentalmente una colonna. Uno dei DBA sposta le tabelle su uno schema diverso. Un database diventa danneggiato.

Queste sono alcune delle cose che ho visto accadere nei database di produzione live nel corso degli anni. Ognuno mi ha fatto molto piacere che ci fossero backup delle applicazioni di produzione.

Ci sarà sempre qualcosa che va storto. Questo è uno dei motivi per cui si ha il codice di gestione degli errori nelle applicazioni di produzione: per impedire che una sezione del codice provochi l'errore generale di tutto questo.

Errori

Registra tutto ciò che è un errore con il maggior numero di dettagli possibile. Includi il messaggio di errore completo (ove possibile). Assicurati che il tuo codice possa essere chiuso correttamente quando un errore è sufficientemente dannoso da richiederlo. E ricorda che la tua app si è conclusa con la forza. Mostrare errori all'utente è qualcosa che dovresti fare nella maggior parte, ma non in tutte le circostanze.

Avvertenze

Registra avvisi, ma acquisisci solo le informazioni minime necessarie per diagnosticare e correggere il problema. È possibile che si desideri impostare un flag che consenta in via condizionale di registrare gli avvisi (e / o i messaggi informativi). Questo aiuterà a mantenere il file di registro piccolo. I messaggi di avviso sono per lo più qualcosa che vorresti mostrare all'utente, specialmente quando l'utente può apportare modifiche per correggere il problema.

Messaggi informativi

Registra solo gli elementi informativi quando hai bisogno di informazioni normalmente non importanti. Nel codice di produzione, ho trovato utile che i messaggi informativi includessero quando si entra e si lascia una funzione, un metodo, proprietà (quando fanno più valori get / put), avvia e chiude le istanze singleton (ad es. SerialPort). Questi messaggi informativi non devono essere mostrati all'utente.

Idealmente, NESSUN cambiamento inaspettato accade a un sistema di produzione, MAI.
In realtà, naturalmente, accadono tutto il tempo.

Il modo in cui lo gestisci consiste nell'avere procedure adeguate per ridurle al minimo e avere a disposizione procedure adeguate per gestirle quando accadono (elenchi di persone da chiamare, cose da controllare, processi di rollback, ecc. Ecc.
Il rischio può anche essere ridotto testando correttamente tutte le modifiche che sono pianificate nel miglior modo possibile, in una situazione il più vicino possibile al sistema vitale (ad esempio configurazione hardware e software identica), quindi con procedure in atto che rendono imperativo che non vengono apportate modifiche manuali ai sistemi di produzione ad eccezione di quelli elencati esplicitamente nei manuali di aggiornamento / installazione del prodotto.

Si noti che non c'è un singolo software di monitoraggio, nessuna pratica di codifica, niente di tecnico. È tutto procedurale e documentazione.

Combinalo con un adeguato controllo degli accessi ai sistemi di produzione (in pratica solo le persone che eseguono installazioni e disaster recovery hanno accesso in scrittura lì, e con la procedura accedono solo con quegli account specifici quando eseguono quelle attività specifiche) e hai fatto tutto ciò can.
L'unica cosa da fare nel codice è renderlo il più robusto possibile verso le modifiche dello schema.
Ovviamente non è possibile evitare una colonna che è necessario eliminare o rendere il suo tipo di dati più ristretto. Ma puoi evitare che una colonna cambi in NOT NULL assicurandoti che tutte le colonne siano sempre scritte con valori, e puoi evitare la maggior parte delle aggiunte di colonne (ovviamente NON le colonne NULL) scrivendo il tuo codice in modo da recuperare e scrivere solo colonne esplicite, solo il set minimo necessario per le tue operazioni.

Non lo fai.

Le modifiche del database / dello schema non sono cose che "semplicemente accadono". Modifiche come questa non sono desiderate o supportate.

Qualsiasi cambiamento che potrebbe essere necessario dovrà passare attraverso la normale gestione delle release e il processo di gestione delle modifiche, che include il test delle funzionalità esistenti (nulla è rotto) e che dimostra che il cambiamento ha l'effetto desiderato. Abbiamo un ambiente di sviluppo, test, messa in scena e produzione solo per questo. Non scriviamo il codice in produzione.

Potrebbe essere necessario un po 'più tempo rispetto alla semplice modifica di un database in produzione, ma è l'unico modo per assicurarsi che gli utenti non si trovino di fronte a errori casuali perché "qualcuno" ha cambiato "qualcosa".

Non puoi codificare uno schema di database che cambia. Cosa succede se il DBA rinomina un tavolo? Cosa succede se il DBA abbandona i record correlati? Cosa succede se l'amministratore di sistema disabilita la convalida o aggiunge ulteriore convalida?

L'unica opzione valida è registrare gli errori e lasciare che l'applicazione fallisca.

Suggerisco di stabilire regole chiare con il team operativo su questo tipo di cose. Come gli piacerebbe se iniziasse a rinominare i server per loro?

Nel mio ambiente facciamo modifiche dello schema solo come parte di un rilascio, e lo facciamo con strumenti che trasformano lo schema nella forma esatta come progettato. ciò potrebbe essere annullato da altri cambiamenti che possono essere apportati in un ambiente.