Question

I’m considering using Entity Framework 4.3 migrations in a production site. The following is my concern:

If the migration fails for whatever reason, I want all statements
rolled back and the site placed in a down state so no users can use
the site while I try to fix the problem. The only thing is I can’t
fall back to executing the scripts by hand against the database since
migration files are compiled in the assembly. I could keep track of
both migration files and sql script files separately but at that point why use
migrations at all.

At work, script files are stored in a SQL folder (that no one can browse to) on the site. Previously run script files are registered in the database. When new script files appear in the folder (and aren’t in the database), if a user is an admin, they’ll be redirected to a DB portal, else get a site-down-for-maintenance. If we try and fail to execute any scripts from the portal, we grab the new scripts and try to run them manual inside of express studio. This has worked for over a decade. I’m only exploring migrations to see if a better way has arrived. It doesn’t feel like it. Please let me know if there’s a better way and if it’s not Migrations, what is it.

Answer 1

I would definitely not use automatic migrations in a production environment. In fact, I’m too much of a control freak to use automatic migrations at all. I prefer code based migrations to ensure that all databases (developers’ own personal, test environment, production) have gone through exactly the same update sequence.

Using code-based migrations where each migration step gets a name, a separate migration script can be generated for use when lifting test and prod environments. Preferably it should be run on a copy of the database to validate before running on the real prod environment.

Added Later

To prevent EF Migrations from doing anything automatic at all, a custom initializer strategy can be used. See my blog or the Deploying EF Code First Apps to Production Database Stack Overflow question.