Ciao,

ho un'applicazione Asp.net che sto realizzando ed è basata su EF Code First come ORM.
In locale tutte le modifiche al modello le riporto sul db grazie ai migration tool offerti.

A breve però dovrò pubblicare la web app su Azure, basandomi sul servizio SQL Azure e non mi è chiaro come poi potrò mantenere allineato il db Azure rispetto a future modiche che farò in ambiente di sviluppo.

In genere mi scrivevo tutto il DAL a mano quindi tenevo traccia di tutte le modifiche su un file di progetto che committavo sul GIT di volta in volta.
Al rilascio di una nuova release eseguivo gli script sql ed avevo quindi il db allineato alla versione del codice.

Come si procede invece con EF Code First per ottenere lo stesso risultato una volta che si è in produzione e quindi non si può ovviamente rigenerare il db da zero?

Grazie e ciao!

Ciao,
dovresti provare le Code First Migrations, che ti permetteranno di aggiornare lo schema del database in base alle modifiche che avrai apportato alle entità del tuo modello.

Si tratta sostanzialmente di usare due comandi dal riquadro di installazione pacchetti di Visual Studio.

• Add-Migration nomemigrazione, che servirà a generare una migration che è un file di codice C# che descrive i cambiamenti che andranno apportati al database affinché sia adatto a persistere le entità del tuo modello. Questo significa che il file .cs conterrà le istruzioni per generare tabelle, aggiungere colonne, indici e così via.
• Update-Database è il comando che eseguirà le istruzioni indicate dalla/e migration. Il database viene controllato per verificare quale sia la situazione attuale del suo schema, e poi vengono eseguite le migrations non ancora applicate. Per fare questo lavoro in produzione è consigliato passare il flag -Script, che non aggiornerà il database ma si limiterà a produrre uno script SQL che puoi controllare e poi lanciare in tutta comodità da Sql Server Management Studio.

C'è un inghippo: quando lanci Update-Database, il comando userà la connectionstring che hai nel web.config e quindi l'aggiornamento (o la generazione dello script), avverranno nei confronti di quel database, che potrebbe essere quello locale che usi per lo sviluppo e che potrebbe non essere allineato alla stessa migrazione del db di produzione. Quindi è necessario passare un ulteriore parametro -ConnectionStringName "NomeConnectionStringDiProduzione" per evitare che distrattamente tu esegua operazioni non volute nei confronti del db di produzione.

Nessun dato andrà perso a meno che non sia tu a volerlo impostando la proprietà DataLossAllowed.
https://msdn.microsoft.com/it-it/data/jj591621.aspx

Necessità di un po' di pratica ma poi si rivelerà uno strumento molto utile.


ciao,
Moreno