Flyway / Liquibase per struttura del database e dbunit per inserti del database?

Question

Ho il seguente scenario per la mia applicazione:

.
• 1 Server di produzione
• 1 test server
• N Computer di sviluppo

  Per la migrazione del database utilizziamo l'aggiornamento dello schema Hibernate per lo schema e Dbunit per il riempimento dei dati di produzione (su tutti i server / computer). Quando viene eseguito l'aggiornamento dello schema, Genera un nuovo file DTD per il nuovo schema, quindi posso fare una nuova importazione di Dbunit XML. L'applicazione aggiorna il database all'avvio con il file XML (solo su server di sviluppo e test / computer!)

  certo questo approccio non è ottimale e fragile. Così ho guardato Liquibase e Flyway. Entrambi sembrano essere grandi strumenti, ma quello che non capisco è: come migrare i dati? Nel mio caso, dumando i dati del sistema di produzione una volta alla settimana e lo aggiungi al controllo dell'origine delle applicazioni come file Dbunit XML, quindi tutti gli sviluppatori hanno dati "freschi" e il server di test dispone anche di dati di produzione attuali. .

  Il problema che vedo con Liquibase e Flyway è che non è presente alcuna soluzione come fare i diffs automatizzati dai dati del database e generare automaticamente le modifiche alla migrazione.

  Quindi la mia idea è la seguente con i seguenti passaggi:

  .
  1. Imposta ibernazione per convalidare invece di aggiornamento.
  2. Quando è necessaria una modifica del database strutturale, lo aggiungo allo script di migrazione per la versione principale
  3. Nessun inserimento di database è nello script di migrazione.
  4. Genera una nuova DTD per Dbunit in base alla nuova struttura del database
  5. Genera il Dbunit XML dal database di produzione.

     Un'altra idea sarebbe quella di utilizzare Flyways Javamigration e fornire una discarica di database iniziale basata su Dbunit. Tutte le altre modifiche per i dati del database verranno gestite negli script di migrazione. Ma ancora c'è il problema: come creare diffs dall'attuale stato di script migratorio e allo stato del database di produzione?

     Sarebbe fantastico se qualcuno potesse fornirmi suggerimenti come gestire il mio scenario :)

Answer 1

Se il tuo obiettivo è utilizzare dump del database Prod in ambienti di dev e test, vorrei:

.
• Configurare lo strumento di migrazione DB per essere eseguito sull'avvio dell'applicazione (sia flyway che Liquibase supportarlo attraverso le rispettive API)
• Confezione tutte le migrazioni della struttura DB insieme all'app
• Scaricati sia dati che struttura da Prod

  In questo modo, quando il database Prod è ripristinato per dev o test, viene ripristinata anche la vecchia tabella dei metadati dello strumento di migrazione.

  Quando l'app inizia, lo strumento di migrazione scoprirà che la struttura DB è obsoleta e lo aggiornerà alla versione più recente.Fatto.

  Non è necessario utilizzare dbunit per questo.

Answer 2

La risposta breve è che tutte le tue modifiche sarebbero state eseguite tramite Liquibase o Flyway.

Utilizziamo flyway, con lo stesso prodotto Prodotto / test / Sviluppo. Facciamo tutte le modifiche a DB (struttura o metadati) utilizzando gli script di migrazione flyway, memorizzati nel controllo sorgente.Ogni volta che facciamo una nuova implementazione in un ambiente, eseguiamo per la prima volta gli script di migrazione lì (utilizzando lo strumento della riga di comando o il plugin MAVEN).Il codice passa per la prima volta all'ambiente di sviluppo, ottiene l'integrazione testata lì e continua a testare e alla produzione.

La cosa principale da prestare attenzione è che Flyway richiede una versione lineare ai file, quindi se due sviluppatori controllano le migrazioni allo stesso tempo, uno di loro dovrà rinominare il loro.