workflow nhibernate + migrations

Question

Sto cercando di perfezionare il mio flusso di lavoro attorno a NHibernate e uno schema che cambia frequentemente e il modo migliore per affrontarlo - Vorrei che la stessa soluzione si applicasse ai sistemi di produzione, quindi penso di aver bisogno di un motore di migrazione anziché solo aggiornamento dello schema.

Quello che voglio sapere è come posso perfezionare il flusso di lavoro il più lontano possibile in modo da fare meno lavoro possibile per ottenere il mio database in sincronia con il mio modello di dominio. L'approccio agli script di tarantino sembra buono, ma non sembra essere un modo per generare lo script di aggiornamento dai miei mappaggi nHibernate, quindi sono a disposizione per creare uno script o utilizzare uno strumento di confronto di sql redgate. C'è qualcosa che mi manca che renderebbe la vita più facile nella fase di generazione della sceneggiatura?

Grazie, Chris

Answer 1

non ho usato uno di questi migration tools for .net me stesso, ma quando si cerca di Ruby on Rails su mio tempo libero qualche anno fa, ho visto i benefici delle migrazioni rispetto al T-SQL script che abbiamo usato nel mio lavoro in quel momento.

Answer 2

In un recente progetto che ho svolto, abbiamo scoperto che le migrazioni, combinate con la ramificazione VCS e NHibernate, possono causare numerosi mal di testa e inconvenienti lungo il percorso.

Quello che abbiamo fatto è stato configurare NHibernate per generare lo schema con ogni build automatizzata (per l'ambiente di sviluppo) insieme ad alcuni dati di caricamento.

Per l'ambiente di produzione, disponevamo di uno script basato sullo schema corrente e sullo schema desiderato, generato una migrazione con i campi e le modifiche necessari.

Answer 3

Utilizziamo SQL Compare. È pagato ma vale la pena di investire. Mantieni tutti gli script generati ben organizzati, ad esempio quelli con data e ora, e ottieni un buon modo di generare il database per qualsiasi versione rilasciata.

Questo è il nostro solito flusso

1. Durante DEV abbiamo due basi di dati "Nome progetto" e "ProjectName_TEST".
2. Per ogni modifica dello schema generiamo (NHibernate) un nuovo database e sostituiamo "ProjectName_TEST".
3. Utilizziamo SQL Compare per aggiornare "ProjectName" (mantenendo quindi tutti i dati dev in esso)
4. Al rilascio, confrontiamo "ProjectName_TEST" con il database di produzione e generiamo uno script di aggiornamento.

Dai un'occhiata allo command line options poiché sono abbastanza utili per automatizzare il processo tramite eventi di generazione VS.