Efcore: Where can I find tutorial for deployment of entity framework migrations to production?

[arielcloud]

Is it good practice to update production database by calling
context.Database.Migrate(); from inside the app?

(We want that application will be down if it not synced with DB, and with this code I get it free).

Sorry for opening this issue, but I can't find no tutorial / blog etc. about best practices for deployment of code first migrations.

thanks!

[julielerman]

If Pluralsight is an option, Michael Perry recently published a course on Pluralsight called http://app.pluralsight.com/courses/entity-framework-migrations-large-teams. I also have an older migrations course and more migrations details in a few other EF courses, but my guess is that Michael's will have what you are looking for since it is the focus.

[divega]

Triage: possibly a docs bug.

[gdoron]

@arielcloud I think not.
Updating production database without really knowing which scripts are going to run is really reckless INHO.

You should generate the script:
$> dotnet ef migrations script -h

And let your DBA review it and run it on production.
(Or run it yourself if you understand the code)

That's my 1.9 cents

[gdoron]

See #6110 for knowing which migrations weren't applied yet.

[natemcmaster]

@divega it's on our radar for docs. https://github.com/aspnet/EntityFramework.Docs/issues/204

[divega]

Thanks @natemcmaster Closing as a dupe but others, feel free to provide additional recommendations.

[arielcloud]

@gdoron So, Is it good practice that we run db changes differently in development env (by migrations) vs prod env (by script)?
In my previous app (with nhibernate) we run all migrations as script in all envs the same way.
thanks!

[gdoron]

@arielcloud I don't think there's a right or wrong answer and it's best for you to consult with your team/DBA.

If you review the migration script as early as possible you might catch errors with the migration script sooner than later, so it's good to review the migration once you create it.

But if you need someone else to review the script (DBA or a more experienced developer), he might not want to be bothered unless it's a production ready script.

So it's up to your company to decide which method is the best for you.
BTW, Julie Lerman linked a Pluralsight course that you might want to watch (I haven't watched it yet).

[arielcloud]

@gdoron the Pluralsight course is about EF6. I saw the most, and it wasn't so helpful with this topic.

I prefer to use the same way for db upgrade in all envs to be sure I get the same results (and I'm also the DBA).
So, once we review any migration script immediately when migration created, I can't see any difference how we apply it later on production, and we can do it the same way as in development (by run generated scripts / by "dotnet ef database update" / by apply the migrations by code as in the first comment on both envs?)...

[gdoron]

I think it depends on what kind of application you're building.
If it's a news website, go ahead, review in on development and run it automatically on all other environments.

If it's a financial application please do review the script before running it on production.

Anyway, I think you got all the information needed, it's up to you to decide what works best for you and your team.