Questo è ciò che facciamo, ma siamo sviluppatori PHP non VS quindi forse Microsoft ha un approccio migliore, ma l'idea dovrebbe essere la stessa.
Manteniamo una tabella dei log delle modifiche nel database. Ogni volta che gli script di aggiornamento vengono eseguiti, questa tabella viene aggiornata per riflettere lo stato corrente del database. Mantiene anche una cronologia delle modifiche (questo ti consente di individuare i database dei clienti che potrebbero avere degli hotfix speciali installati che altri non hanno).
CREATE TABLE 'changelogs' (
'id' int(10) unsigned NOT NULL AUTO_INCREMENT,
'version' varchar(45) NOT NULL,
'previous' varchar(45) NOT NULL,
'log' text,
'started' datetime DEFAULT NULL,
'finished' datetime DEFAULT NULL,
'created' datetime NOT NULL,
PRIMARY KEY ('id'),
KEY 'created' ('created')
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=latin1$$
Ci sono due tipi di aggiornamenti dal controllo del codice sorgente che gli sviluppatori dovranno conoscere.
-
L'aggiornamento è ridondante, il che significa che possono semplicemente cancellare un record dai loro log delle modifiche del database e rieseguire gli aggiornamenti. Gli aggiornamenti non richiedono un punto critico nello schema.
-
L'aggiornamento è dipendente e devono riportare il database a una versione stabile in modo che gli aggiornamenti possano portarlo in avanti. Gli aggiornamenti richiedono uno schema specifico.
Mentre i clienti possono eseguire la versione 2.0.0 del database. Gli sviluppatori possono solo eseguire il rollback a 2.9.9 per testare l'aggiornamento a 3.0.0 (beta). Puoi anche eseguire il downgrade degli script che eseguono rapidamente hack sul database per rendere sicuri gli aggiornamenti da eseguire.
Il processo di aggiornamento è fondamentalmente una tecnica automatizzata di tua scelta. Usiamo una directory in ogni progetto che memorizza un elenco di file SQL. Il contenuto della directory assomiglia a questo.
install.sql
update.txt
update-2.0.0.sql
update-2.0.1.sql
update-3.0.0.sql
hotfix-3.0.1.sql
install.sql è il nostro script di immissione del punto zero. Crea il database per le nuove installazioni.
update.txt è la nostra guida agli aggiornamenti per lo script di distribuzione, mentre il resto sono file SQL da eseguire.
Il contenuto di update.txt assomiglia a questo.
#
# Defines the update mapping of which SQL files are executed.
# The order of this file isn't important, but do not create
# endless circular versions (i.e. update 3 to 4, then 4 down to 3).
#
# Usage for each line:
# [current_version]=update-[new_version].sql
#
3.3.14=update-3.4.0.sql
# DATE: 20130107 144921
3.4.0=update-3.4.1.sql
L'unico valore che lo script di implementazione comprende è la prima parte current_verion . Quello è uguale a un file. Quando viene eseguito lo script di distribuzione, legge la versione corrente dalla tabella changelogs e quindi esegue il file SQL che corrisponde a quella versione. Questo fa avanzare il database nelle modifiche dello schema. Questo processo si ripete finché non ci sono più corrispondenze nel file update.txt (l'ordine nel file non è importante).
Questo approccio funziona bene per noi. Siamo in grado di individuare i clienti con gli hotfix, ma continuiamo a migrare verso versioni ufficiali successive. Installa anche piccoli file di modifica SQL per aggiornarli dal loro hotfit.
L'unico problema con questo approccio è che richiede disciplina da parte dello sviluppatore. Separiamo questo processo anche dal modulo software, piuttosto che da una directory di aggiornamento di grandi dimensioni per applicazione. Per ogni modulo, prefixiamo la tabella changelog . Quindi abbiamo più tabelle chiamate cose come documents_changelog e users_changelog . Questo ha funzionato bene per noi poiché i moduli sono condivisi su più applicazioni.