Come sincronizzi le modifiche ai dati nel tuo database? [chiuso]

Question

Come sincronizzi le modifiche ai dati nel tuo database? [chiuso]

#1 da (9 voti)
#2 da (4 voti)

2

Sono nuovo in un team che sviluppa un'applicazione web molto grande. Prima della mia partenza, il team aveva già installato 0 automazione e ha fatto tutto a mano. Questo è stato possibile perché erano solo una squadra di 2. Ora sto gradualmente cambiando questo, ma ovviamente non posso semplicemente far ripartire tutti da zero e "farlo bene".

Un problema con cui sto combattendo sono le modifiche ai dati (non allo schema) nel database. Ci sono parecchie cose che sono configurate nel database, come traduzioni, navigazioni, ruoli / permessi e modelli di posta. Fortunatamente questi sono solitamente definiti dal team e spinti alla messa in scena / produzione, non in entrambi i modi.

La nostra configurazione è che ogni dev ha il proprio ambiente di sviluppo e il proprio database. Poi c'è un ambiente di allestimento e produzione. L'idea è che un dev possa creare le sue nuove voci di navigazione, i permessi e le traduzioni sulla sua casella di sviluppo, quindi applicare in qualche modo queste modifiche a a) le altre caselle di sviluppo eb) la messa in scena e la produzione.

Il modo ovvio per monitorare queste modifiche è archiviarle come codice o file SQL, tuttavia questo diventa piuttosto complicato considerando che un modello di posta memorizza i suoi dati in 3-4 tabelle e ha chiavi esterne. Un altro modo sarebbe creare funzionalità di esportazione / importazione, ma sarebbe molto dispendioso in termini di tempo.

So che questo argomento è stato discusso prima, ma di solito la discussione si conclude con "traccia le tue modifiche nei file sequenziali di sql o di codice". Spero di sapere cosa potrebbero fare gli altri team e forse c'è anche un ottimo strumento per gestirlo in qualche modo in modo generico?

version-control database data changes

posta Christof 18.08.2015 - 14:15

fonte

2 risposte

Leggi altre domande sui tag version-control database data changes

Perché usare XML in Android? Revisione del codice e linee guida per il check-in: i revisori hanno il potere di veto sul check-in? [chiuso]

score 9 · Answer 1

Gli script SQL sono la soluzione giusta:

Le informazioni sono state originariamente create tramite istruzioni SQL, la più affidabile ripetibilità derivava dallo stesso script
L'importazione / esportazione può anche diventare complicato se due sviluppatori stanno modificando la stessa tabella.
È difficile riesaminare il codice di un file di esportazione.
È difficile eseguire il debug di un file di esportazione

Abbiamo 5 ambienti di database nel nostro mondo: dev, staging, alpha, beta, production. Gli sviluppatori eseguono i propri script solo contro dev. Sono responsabili del controllo di questi script nel controllo del codice sorgente, proprio come il resto della nostra fonte. Abbiamo un sistema di distribuzione automatizzato che recupera quegli script dal controllo del codice sorgente e li esegue su ogni ambiente successivo.

score 4 · Answer 2

Come hai capito da solo, SQL è la strada da percorrere, ma se inserisci i comandi SQL in script o li incorpori in codice in realtà non fa una grande differenza. Ciò che conta è che tu rendi il processo di aggiornamento solido. Pertanto, consiglierei di prendere in considerazione il seguente miglioramento rispetto a

track your changes in sequential sql or code files

Invece, traccia le tue modifiche (in sql e / o file di codice) che funzionano anche quando sono non eseguite nella sequenza originale, o quando vengono eseguite due volte. Rendili idempotenti . In uno dei nostri sistemi, utilizziamo un flag table per questo scopo, in cui ogni modifica ai dati del database è contrassegnata da un flag. Lo pseudocodice per l'aggiornamento del database è quindi simile a

 ' part added by developer A during development of feature "Foo"
 IF NOT CheckFlagTableIfUpgradeFooAlreadyApplied() THEN
     IF ApplyUpgradeFoo() = SUCCESS THEN
        MarkUpgradeFooInFlagTable()
        COMMIT
     ELSE
        ROLLBACK
        WriteToLog("UpgradeFooFailed")
     END IF
 END IF

 ' part added by developer B during development of feature "Bar"
 IF NOT CheckFlagTableIfUpgradeBarAlreadyApplied() THEN
     IF ApplyUpgradeBar() = SUCCESS THEN
         MarkUpgradeBarInFlagTable()
         COMMIT
     ELSE
        ROLLBACK
        WriteToLog("UpgradeBarFailed")
     END IF
 END IF

In questo modo, puoi sempre prendere un vecchio database con alcune modifiche applicate e altre no e aggiornarlo allo stato più recente. Ad esempio, lo script sopra funzionerà quando mancano le modifiche "Foo" e "Bar", quando è stata applicata solo la modifica "Foo", solo la modifica "Bar" o entrambe. È anche molto facile aggiungere post-condizioni in questo modo, per gestire casi di aggiornamenti interdipendenti. Le modifiche dello schema possono essere gestite in modo simile, ma spesso non è nemmeno necessario un flag table: basta implementare un metodo di test come DoesColumnXYZExist() per verificare se una colonna specifica è già stata aggiunta allo schema.

Ciò rende tutto più semplice e affidabile quando le persone lavorano in parallelo per integrare le modifiche del database in momenti diversi a tutti i loro diversi database di sviluppo e ai database di staging, testing o produzione.

Vedi anche questa domanda precedente sui programmatori , dove è stato menzionato uno strumento denominato Liquibase per l'implementazione di questo processo.