È corretto aggiornare un database di produzione con migrazioni EF?

Secondo questo post sul blog, la maggior parte delle aziende che utilizzano Migrazioni EF probabilmente non aggiornano lo schema del database dei database di produzione con le migrazioni EF. Invece l’autore del post del blog raccomanda di utilizzare gli script di aggiornamento dello schema come parte del processo di distribuzione.

Ho usato gli script di aggiornamento Schema per alcuni anni e mentre funzionano, stavo progettando di utilizzare le migrazioni EF invece in futuro per i seguenti motivi:

  • Implementazione più rapida, meno tempi di inattività
  • Una procedura di distribuzione più semplice
  • Migrazione molto più semplice dei dati esistenti di quanto sarebbe ansible con T-SQL
  • Una syntax più comprensibile delle modifiche in attesa di essere applicate (class DbMigration con syntax C # pulita rispetto allo script di migrazione T-SQL clunky in un ambiente tradizionale).
  • Esiste un percorso di downgrade facile e veloce per il vecchio schema db se la distribuzione della nuova versione del software dovesse fallire

Una ragione per cui posso pensare che proibirebbe l’uso di EF per migrare un DB di produzione sarebbe se lo schema DB fosse modificato solo dai DBAs in opposizione agli Sviluppatori. Tuttavia, sono sia DBA che Developer, quindi non è importante nel mio caso.

Quindi, quali sono i rischi dell’aggiornamento di un database di produzione usando EF?

Edit: Vorrei aggiungere che, come già suggerito solomon8718, sto sempre tirando una nuova copia del database di produzione sul mio server di staging e testare le Migrazioni EF da applicare sul server di staging prima di applicarle a un server di produzione. IMO questo è essenziale per qualsiasi aggiornamento dello schema di un sistema di produzione, sia che io stia utilizzando o meno le migrazioni EF.

Bene, cercherò di rispondere comunque. Direi No, non c’è motivo per non utilizzare Code First Migrations in produzione. Dopo tutto, qual è il punto di questo sistema facile da usare se non riesci a portarlo fino in fondo?

I maggiori problemi che vedo con esso sono tutti i problemi che puoi avere con qualsiasi sistema, che hai già notato. Fintanto che l’intero team (incluso DBA se applicabile) è a bordo, penso che consentire a EF di gestire lo schema attraverso le migrazioni sia meno complesso e quindi meno sobject a errori rispetto alla tradizionale gestione basata su script. Farei ancora un backup prima di eseguire una migrazione su un sistema di produzione, ma lo faresti comunque.

Nulla dice che un DBA non possa eseguire una migrazione da Visual Studio. L’accesso potrebbe ancora essere bloccato con privilegi a livello di database e lui / lei potrebbe rivedere la migrazione (in un utile formato di esportazione SQL usando -Script , se lo si desidera) prima di eseguire l’operazione effettiva. Quindi hanno ancora il controllo, ma puoi utilizzare le migrazioni code-first. Diavolo, potrebbero persino finire per piacergli!

Aggiornamento: dal momento che SPROC e TVF sono stati triggersti, gestiamo anche quelli in migrazioni, sebbene siano effettivamente eseguiti con istruzioni SQL DbMigration.Sql() utilizzando una chiamata DbMigration.Sql() in Up() , e il contrario di essi nel Down() (È anche ansible utilizzare CreateStoredProcedure e DropStoredProcedure per DropStoredProcedure semplici, ma penso che sia ancora necessario definire il corpo stesso in SQL). Immagino tu possa dire che è un avvertimento; non esiste ancora un modo per scrivere un intero database completo esclusivamente in C #. Tuttavia, è ansible utilizzare le migrazioni che includono script SQL per gestire l’intero schema. Un vantaggio che abbiamo trovato da questo processo è che puoi usare il file di configurazione C # per i nomi degli oggetti dello schema (diversi nomi di server per production vs dev per esempio) con un semplice String.Format , combinato con XML Transformation per i file di configurazione stessi.

Sì, esistono buoni motivi per non utilizzare un sistema automatizzato come Code First Migrations per apportare modifiche al database di produzione . Ma come sempre ci sono delle eccezioni alle regole.

  1. Una ragione che è stata menzionata sarebbero le autorizzazioni di accesso, che sarebbero direttamente correlate alle regole di gestione delle modifiche e alle politiche di sicurezza dell’organizzazione.

  2. Un altro motivo potrebbe essere il tuo livello di fiducia nello strumento Migrations stesso. Siamo sicuri che lo strumento non abbia un bug in esso? Cosa succede se lo strumento si guasta a metà strada? Sei sicuro di avere backup aggiornati e un processo di rollback, se necessario?

  3. Gli script di modifica possono eseguire script inaspettati o inefficienti. Ho riscontrato casi in cui sql ha generato i dati copiati in una tabella temporanea, ha abbandonato la tabella originale, quindi ha ricreato la tabella originale per cose come l’aggiunta di una nuova colonna se si modifica involontariamente (o intenzionalmente) l’ordine in cui appare la colonna, o quando si rinomina il tavolo. Se sono coinvolti milioni di record, ciò potrebbe causare seri problemi di prestazioni.

La mia raccomandazione:

Supponendo che si disponga di un database di gestione temporanea che rispecchia lo schema di produzione, utilizzare lo strumento Migrazioni per generare gli script di modifica su tale sistema. Di solito ripristiniamo il nostro database di stage da una nuova copia di produzione prima dell’esecuzione. Esaminiamo quindi manualmente gli script di modifica per verificare eventuali problemi. Successivamente, eseguiamo gli script sul nostro database stage per assicurarci che venga eseguito correttamente e che tutte le modifiche previste siano avvenute. Ora siamo sicuri che gli script siano entrambi sicuri per essere eseguiti in produzione ed eseguire le modifiche previste. Questo processo dovrebbe affrontare tutti e tre i problemi che ho elencato sopra.

Un’altra avvertenza che ho trovato: se si dispone di diversi siti Web che utilizzano lo stesso contesto di dati, è necessario assicurarsi che tutti vengano aggiornati contemporaneamente. Altrimenti potrebbe esserci un costante aggiornamento del database / scontro di downgrade tra i siti web. A parte questo, ha funzionato bene per me.

EDIT: il mio punto di vista un anno dopo aver iniziato a utilizzare EF Migrations in produzione:

EF Migrations è in realtà piuttosto interessante, anche per uso produttivo, a condizione che tu

  1. Testare le migrazioni su un sistema di gestione temporanea. Eseguo il test di tutte le migrazioni eseguendo la migrazione verso il basso e di nuovo sul mio server CI prima di eseguire i test di integrazione.
  2. Non triggersre automaticamente le migrazioni, ma con un file batch avviato da un amministratore. Ciò è essenzialmente uguale all’esecuzione manuale di SQL per una migrazione in SSMS.

Lo uso in produzione per un paio di progetti. Una volta capito, penso che vada bene.

Durante lo sviluppo è ansible mantenere le migrazioni automatiche ma alla fine è ansible connettersi al db live direttamente dalla console del gestore pacchetti e generare una migrazione. Ti darà una migrazione per tutte le modifiche.

Ma sempre sempre usa sempre l’opzione -script con update-database e triggers tu stesso l’SQL.

Vorrei anche consigliare di non utilizzare l’opzione db di aggiornamento dalla distribuzione Web. In questo modo non c’è modo di sapere quanta parte della migrazione è già stata generata per errore. Mi sono imbattuto in problemi con questo alcune volte. Quindi meglio ottenere l’SQL e spararlo manualmente.