How to manage Migrations in a project with multiple branches?

Question

I have an ASP.NET MVC3 project that uses Entity Framework 4.3 with the code-first approach. I use Migrations to keep the database up-to-date.

The project is under so

Answer 1

I think what @LavaEater is saying makes a lot of sense. I'm implementing a branching strategy (Development, Main, Release) and aligning it with the environments in the development, QA and release process.

• Development branch - Local development
• Main branch - Merge changes from Development branch and deploy to my Staging environment (an Azure website and SQL database)
• Release branch - Merge changes from Main and deploy to Production environment (another Azure website and SQL database)

I've come up against the problem discussed above and in my opinion the complications around migrations and the potential workarounds introduce a great deal of risk into the release process. Executing independent migrations in Development, Main and Release effectively means that the schema I included in the build in Dev is not the schema that goes into QA on Staging and the schema that QA signs off on Staging is not the schema that is deployed to Live (unless I follow one of the suggested solutions which I'm sure would work but may be error prone).

To echo @LavaEater - what is the real benefit I get from EF code first? Personally, I think it's the ease with which I can generate a schema from code (and potentially tweak the automatically generated migrations if I want to). After that, migrations are a complication of what should be a simple deployment process.

My current thinking is to use code first to generate the migrations in development and then either:-

• Option A) - Use Update-Database -script to script up the schema changes and put them under source control. There is still some potential for conflicts if 2 people are amending the same model but I think that it's easier to manage.

• Option B) - Use something like SQL Compare to generate schema change scripts. This is potentially more flexible and transparent as I like to see exactly what schema changes I'm applying to my Production database (call me paranoid).

Am I missing something? I imagine there will be some configuration to do to disable code first migrations in the Main and Release branches (on the assumption that the DB will be created and updated by scripts). Other than that it feels like a safe solution but I would value a 2nd opinion.