ASP.NET MVC 4, Migrations - How to run 'update-database' on a production server

Question

I can use package manager to run \'update-database -verbose\' locally.

Probably a stupid question but I can\'t find it online - once my website is deployed - how can I r

Answer 1

You can get the scripts using EF commands (update-database -script) or you can write the script manually. This is not the most important thing about updating the database in production environment. For me, the most important thing is to be sure that all the scripts were run correctly and they have affected records as expected. In my opinion, you should have a preproduction environment and the database should be a copy of the production environment. This way, you can run the scripts and deploy the application in a pretty similar environment and see if there are any problems. Sometimes the scripts are executed correctly in DEV environment but they fail in production environment. To avoid a headache, you should simulate the production environment in a preproduction environment. Regarding the scripts, if the team has more than one developer I prefer to categorize the scripts in structure scripts and data scripts. Structure scripts alters the structure of the database (add a table, add a column to a table, etc.) and data scripts inserts/updates/deletes records. Also, each script should specify its dependencies so they cannot be executed in the wrong order. A data script that inserts rows in table A cannot be executed until table A has been created. This is what I do: -Define a table for registering the executed scripts. For example: ExecutedScriptsHistory. -Each script has a number and a name. -After a script is executed, a new row is inserted in table ExecutedScriptsHistory. -Before a script is executed, it checks its dependencies. In order to do that, it checks if the scripts have been executed (exists in table ExecutedScriptsHistory).

After you have run the scripts, you can check if all the scripts have been executed checking ExecutedScriptsHistory. This strategy is similar to the one chosen by Microsoft in EF Migration but you have full control of it.