2

I would like to know what would be the best guide to follow and things to consider if i would want to Add Migrations to a Project and note that the project:

  • is live (dev/staging/production environments)
  • Model of the live versions has changed and some fields/tables are removed/added
  • is hosted with Azure App Service (Publish settings)
  • is an MVC project with Entity Framework 6 using code first

I know the basics of adding/using migrations but that's it. I would like to know how i can implement migrations to my solution, publish the new project (changed model) without losing any data.

Is this possible and can anyone suggest me anything to look at that is well explained for this kind of setup?

EDIT I am testing this on development but i can't make it work without having my database recreated, hence losing existing data...

My configuration file:

public Configuration()
{
    AutomaticMigrationsEnabled = true; // tried false as well
    ContextKey = "ContractCare.Models.ApplicationDbContext";
    AutomaticMigrationDataLossAllowed = false;
}

Kind regards

Dimitri
  • 1,185
  • 2
  • 15
  • 37
  • 1
    "some fields/tables are removed/added" - you will need to explain that better. In Code First the database is created based on your code models. When they change,migrations can be used to update the database. So normally when adding migrations to an existing project, you would create an initial migration that captures the current state. Subsequent migrations will then update the database with incremental changes. If staging and prod are different than this initial snapshot you will need to manually get them to match the DEV baseline. – Steve Greene Dec 20 '18 at 14:28
  • I have a existing database based on a model that is no more the same as it is today and there is data in this database. I didn't had migrations enabled at that time. Now i want to make use of migrations but having a different model than the one that has data, where some properties and classes are no more or where properties and classes have been added (classes are DbSet's). I struggle to find a way of deploying/publishing this newer version of my model to a App Service but keeping the data that already resides in the database. – Dimitri Dec 20 '18 at 14:52
  • Running migrations does not delete data. If you remove a column, then yes, data would be lost. We do not run our migrations in PROD. We generate scripts from the migrations for that very reason. – Steve Greene Dec 20 '18 at 15:35
  • @SteveGreene Running a migration is nothing different than generating a script from it and run that. Do you mean that you check and modify that script before? – Sentry Dec 20 '18 at 16:46
  • @Dimitri Your problem is not with migrations, but with changing the database in whatever way. You have to thoroughly check that everything is fine in a DEV or TEST environment – Sentry Dec 20 '18 at 16:46
  • 1
    @Sentry Our DBA's do not allow direct migrations against PROD. There are some differences :) See [here](https://stackoverflow.com/questions/29746937/is-it-ok-to-update-a-production-database-with-ef-migrations) and [here](https://cpratt.co/migrating-production-database-with-entity-framework-code-first/). – Steve Greene Dec 20 '18 at 17:06
  • 1
    @SteveGreene You're right, migrations directly from the application need the right permissions. I guess that two links you provided could also be the answer OP is looking for – Sentry Dec 21 '18 at 09:41
  • Hi all and sorry for the late response, i was on holiday and just have a newborn daughter. @SteveGreene, i don't quite understand how to interpret both links and how this could/should be applied in my case. Can you elaborate on anything for that matter please? Thank you for your understanding. – Dimitri Jan 16 '19 at 11:27

1 Answers1

3

Add an empty snapshot migration to your DEV environement. This will capture the current state of that model:

enable-migrations
Add-Migration InitialBaseline –IgnoreChanges  // Tells EF not generate Up() code of existing objects
update-database

Now all subsequent changes in DEV can be deployed to other environments either by changing the connect string and re-running or by generating a script that can be run on those servers update-database -Script.

Before that, you have to "catch up" the other environments to the state of DEV using the processes you already have in place. Then you apply the InitialBaseline migration to those environments.

Moving forward you can apply the DEV migrations to UAT, STG and eventually PROD. Since a lot of migrations tend to happen in DEV, you can roll those up into a single migration as Chris explains here.

Steve Greene
  • 12,029
  • 1
  • 33
  • 54
  • thank you for the fast and detailed explanation. I will try to implement this either tomorrow or next week and will get back here with the results. – Dimitri Jan 17 '19 at 14:20