Gestione delle modifiche dello schema del database quando si esegue il push di nuove versioni

Durante i periodi di forte sviluppo, lo schema del database cambia sia rapidamente che continuamente e, quando arriva la nostra spinta settimanale alla build beta, lo schema è cambiato così tanto che l'unica opzione sensata è quella di cancellare tutte le tabelle che posso e copia le nuove versioni dal mio database di sviluppo. Ovviamente, questo non funzionerà una volta lanciato, dal momento che il backup dei dati di produzione è una ricetta per il disastro, quindi mi chiedevo quali strategie esistessero per gestire le modifiche dello schema del database da una versione / revisione a un'altra?

Alcuni che ho trovato o sperimentato:

1. Nuke-and-dump diretto da un database all'altro (cosa sto facendo ora)
2. Mantenimento di un file UPDATE.sql con istruzioni SQL che vengono eseguite manualmente o tramite script.
3. Mantenimento di un file update.php con un valore "versione-schema-versione" corrispondente nel database attivo

La terza opzione sembra essere la più ragionevole, ma esiste ancora la possibilità che una query SQL costruita in modo errato non riesca a metà script, lasciando il database in uno stato semi-aggiornato, richiedendo il ripristino di un backup.

Sembra un non-problema, ma succede, dal momento che come squadra, usiamo phpMyAdmin, e non riesco nemmeno a fare affidamento su di me stesso ricordo di aver copiato l'istruzione SQL eseguita per incollarla nel file update.php. Una volta che accedi a un'altra pagina, devo riscrivere a mano l'istruzione SQL o annullare la modifica e farlo di nuovo.

Immagino che ciò che spero sia una soluzione che non influisca sul flusso di lavoro di sviluppo stabilito?

Automatizzare. Automatizzare. Automatizzare.

Sei sulla strada giusta con un numero di versione DB esplicito, ma farei un ulteriore passo avanti e renderei il codice esplicitamente consapevole di quale schema si aspetta di funzionare (ad es. Eseguendo il commit dello script DDL effettivo e facendo in modo che il programma di aggiornamento lo analizzi ); quindi al momento dell'aggiornamento devi solo scoprire lo schema esistente tramite metadati del database e INSERT / DROP / ALTER secondo necessità, indipendentemente da quale versione a quale versione stai aggiornando. (È inoltre possibile mantenere un numero di versione esplicito nel database stesso e fornire l'intera cronologia dello schema con il programma di installazione in modo che non sia nemmeno necessario il rilevamento dello schema.)

I potenziali errori di sintassi nello script SQL di aggiornamento sono un problema, ma puoi risolverlo verificando che il programma di aggiornamento possa produrre solo istruzioni DDL corrette. (Le prove formali non valgono quasi mai la pena nello sviluppo di software aziendale - troppi sforzi per troppa poca sicurezza - ma ritengo che l'integrità del database sia una delle poche eccezioni: l'SQL di base non è un linguaggio particolarmente difficile da acquisire formalmente e il vantaggio di la protezione dei dati di produzione è talmente grande da giustificare quasi ogni sforzo iniziale, in particolare se deve funzionare per installazioni non presidiate,)

Il controllo delle versioni dello schema del database è la strada da percorrere: ogni versione ha una sola modifica al database o almeno modifiche che possono essere ripristinate nel loro insieme. DBDeploy è un ottimo strumento per automatizzare ciò.

Alcune cose che ho imparato utili sono:

1. Metti sempre alla prova la tua modifica localmente e testa il tuo codice con esso, solo il ALTERpassaggio non è sufficiente
2. È necessario sincronizzare quali sono i primi ad apportare le modifiche: una semplice pagina wiki in cui è possibile "prendere un numero" ha funzionato alla grande per il mio team.
3. Non cercare di riparare il cambiamento rotto, aggiungi un nuovo cambio per negarlo, è molto indolore
4. Il codice dipende da tali modifiche: assicurarsi di collegare i problemi nel sistema di tracciamento dei bug con le modifiche del DB. Questo è molto utile al momento della distribuzione.
5. Includi modifiche DB all'elemento della configurazione: applica le modifiche a un database dell'elemento della configurazione durante il commit. Inoltre, se si dispone di test che utilizzano un database, eseguirli su commit.

Dato che stai usando phpMyAdmin, suppongo che tu stia usando anche MySQL.

Dai un'occhiata ai diagrammi del modello EER in MySQL Workbench. Sono stati di grande aiuto per me nel mantenere e aggiornare gli schemi.

Innanzitutto, è possibile sincronizzare il modello con un'origine del database. In modo che le modifiche nel diagramma vengano inviate come comandi ALTER TABLE. Ciò consente di eseguire le modifiche dello schema sul diagramma, tenerlo sempre aggiornato e, al contempo, inviare aggiornamenti al database di sviluppo quando necessario.

In secondo luogo, è possibile decodificare un diagramma EER da un'origine del database. Che può essere utile apportando modifiche su un database di sviluppo e aggiornando un database di produzione poiché calcolerà le differenze.

In terzo luogo, può essere utilizzato per aiutare a creare l'SQL che dovrebbe andare nel file "update.sql".

CONS:

I trigger e i vincoli del database rappresentano un problema con il programma di aggiornamento della sincronizzazione. Non sembra conoscere il giusto ordine delle cose. I vincoli di chiave esterna spesso generano errori, ma ciò può essere risolto modificando l'SQL che genera.

Questo non è uno strumento di migrazione dei dati. Eventuali modifiche che vanno oltre lo schema puramente necessiteranno comunque di SQL personalizzato.

Dai un'occhiata a http://south.aeracode.org - è una libreria di migrazioni DB per Django (un framework Python) ma:

1. puoi ricavarne grandi idee (e forse anche trovare un clone di PHP)
2. puoi effettivamente usarlo indipendentemente dal resto di Django per gestire le tabelle della tua app PHP / MySQL.

Può anche generare script di aggiornamento dello schema; gestisce inoltre automaticamente le modifiche inverse per la maggior parte del tempo.