Integrazione continua con codice EF Prime migrazioni

Question

Mi chiedevo se potevo automatizzare completamente le migrazioni di codice per l'integrazione continua.

Attualmente la mia integrazione continua semplicemente semplicemente aggiorna il codice cambia, però, ho manualmente generare una migrazione, e aggiornare il database sul mio server di integrazione continua.

È affidabile/possibile/consigliato generare le migrazioni e aggiornare automaticamente il database?

Ad esempio:

ho utente con la proprietà UserID e nome utente. Quindi aggiungo un'età della proprietà nel codice. Lo scenario attuale richiede che crei una migrazione che acquisirà questa modifica e quindi controllerò le modifiche al controllo della versione. L'integrazione continua individuerà questa modifica e distribuirà la nuova versione. Devo aggiornare manualmente il database (che dovrebbe essere automatizzato).

Posso anche saltare la generazione della migrazione, in modo tale che posso semplicemente aggiungere l'età della proprietà al codice e l'integrazione continua genererà questa migrazione. Non sono sicuro se questo è raccomandato.

Answer 1

Parte dell'integrazione continua è anche la possibilità di ripristinare le modifiche errate se non superano i test.

• Scrive gli script di aggiornamento del database in modo che possano essere anche declassati?
• Si creano alcuni punti di salvataggio o backup per ogni commit?
• Si perderebbero dati nel database in caso di backup/ripristini su commit errati?
• Che cos'è un brutto cambiamento nella DDL stessa?

Queste sono alcune delle domande a cui dovresti pensare prima di implementarlo.

Answer 2

La risposta è sì, ma non proprio come la stai descrivendo.

È necessario e dovrebbe generare manualmente la migrazione. Non tutte le migrazioni possono essere create automaticamente e in questi casi è necessaria la modifica manuale della migrazione generata. Divisioni di colonne, determinati tipi di modifiche al tipo di dati, ecc.

Il server CI può quindi utilizzare migrate.exe per sincronizzare i database con il modello. La parte difficile è gestire le migrazioni che comportano downgrade. Quindi passare dalla v1 alla v2 è facile, ma dalla v2 alla v1 è più complicato in quanto solo l'assembly v2 sa come tornare alla v1.

Ho finito per creare uno strumento personalizzato che eseguiva le migrazioni in modo intelligente e determinava automaticamente quale gruppo di modelli (contesto) utilizzare per la migrazione. Puoi avere un'idea di come farlo qui: EF Code First Migrations to Deploy Older Version

Il risultato finale è che posso verificare un cambio di modello/migrazione e sapere che il mio cambio db verrà distribuito automaticamente in qualsiasi ambiente che fa parte del mio ci/cd pipeline - e sì, questo include assolutamente la produzione.