Azure: Best Practice for Testing in a Staging Environment with Code First Migrations

Question

I've got the following setup in Windows Azure:

A "test" hosted service connected to its own "test" database.
A "production" hosted service connected to its own "production" database.

When a build has been verified on test and is ready to go to production, we spin up a "staging" deployment in the production hosted service, and do a quick smoke test to make sure the new build is not totally broken. The staging instance is deployed with the exact bits that will be deployed to production, so it's talking to the production database. When staging is blessed, we hit the "VIP Swap" button, and the build is live on production. All is good.

The problem comes about when the database model changes. I've got Code First Migrations working perfectly. I can add new migrations, apply them locally with the package manager console, and then generate SQL scripts to upgrade the test database when I push a new build to test. The question is, what's the best practice on using Code First Migrations along with staging/production deployments? When I deploy a new build to staging with model changes, it expects to find a database that matches its model. But then if I apply the model changes to the production database, the production instance complains because its model doesn't match.

I've just been skipping the staging smoke test. I upload to staging, then update the production database and hit the "VIP Swap" button pretty much at the same time. Then smoke test on production. If something is majorly broken, "Swap VIP" back and revert the database changes.

Is there a better way to do this, or is that pretty much it?

Thanks!

I'm having the same issue, the only thing i can think of right now is disabling the automatic "upgrade to latest", or expand my own DbMigrator if there is some way to differentiate between staging and production. The best way would be to target a staging db, that could be allowed to upgrade, and then when you swap target another DB.. but since nothing really "happens" when you swap, i cant see how that should happen. — Jim Wolff
This is truly broken. Staging and migrations are incompatible. There is no way to migrate and warm up the staging web server before swapping. The production web server goes down as soon as the migrations are applied. I would assume that the entity framework would be able to handle progressive changes (adding a table for example). It looks like the only way to do this is with a separate staging database. — Rick Love

AvkashChauhan AvkashChauhan · Accepted Answer · 2012-07-04T00:10:49

I am not sure about what is the best practice because I could not find any and it seems users are using what is best suitable for their project and works for them. In one scenario the solution was similar to your plan as you described in which While production DB ws empty and staging database was created with EF code first and migration is applied. Once test was done the scripts were transferred to another database which was later connected with production.

Azure: Best Practice for Testing in a Staging Environment with Code First Migrations

2 Answers