How does azure websites with EF migrations ensure integrity when updating

Question

The scenario is simple: using EF code first migrations, with multiple azure website instances, decent size DB like 100GB (assuming azure SQL), lots of active concurrent users..say 20k for the heck of it.

Goal: push out update, with active users, keep integrity while upgrading.

I've sifted through all the docs I can find. However the core details seem to be missing or I'm blatantly overlooking them. When Azure receives an update request via FTP/git/tfs, how does it process the update? What does it do with active users? For example, does it freeze incoming requests to all instances, let items already processing finish, upgrade/replace each instance, let EF migrations process, then let traffics start again? If it upgrades/refreshes all instances simultaneously, how does it ensure EF migrations run only once? If it refreshes instances live in a rolling upgrade process (upgrade 1 at a time with no inbound traffic freeze), how could it ensure integrity since instances in the older state would/could potentially break?

The main question, what is the real process after it receives the request to update? What are the recommendations for updating a live website?

Answer 1

To put it simply, it doesn't.

EF Migrations and Azure deployment are two very different beasts. Azure deployment gives you a number of options including update and staging slots, you've probably seen
Deploy a web app in Azure App Service, for other readers this is a good start point.

In General the Azure deployment model is concerned about the active connections to the IIS/Web Site stack, in general update ensures uninterrupted user access by taking the instance being deployed out of the load balancer pool and redirecting traffic to the other instances. It then cycles through the instances updating one by one.

This means that at any point in time, during an update deployment there will be multiple versions of your code running at the same time.

If your EF Model has not changed between code versions, then Azure deployment works like a charm, users won't even know that it is happening. But if you need to apply a migration as part of the migration BEWARE

In General, EF will only load the model if the code and DB versions match. It is very hard to use EF Migrations and support multiple code versions of the model at the same time

EF Migrations are largely controlled by the Database Initializer. See Upgrade the database using migrations for details.

As a developer you get to choose how and when the database will be upgraded, but know that if you are using Mirgrations and deployment updates:

1. New code code will not easily run against the old data schema.
2. If the old code/app restarts many default initialization strategies will attempt roll the schema back, if this happens refer to point 1. ;)
3. If you get around the EF model loading up against the wrong version of the schema, you will experience exceptions and general failures when the code tries to use schema elements that are not there

The simplest way to manage a EF migration on a live site is to take all instances of the site down for deployments that include an EF Migration - You can use a maintenance page or a redirect, that's up to you.

If you are going to this trouble, it is probably best to manually apply the DB update, then if it fails you can easily abort the deployment, because it hasn't started yet!

Otherwise, deploy the update and the first instance to spin up will run the migration, if the initializer has been configured to do so...

If you absolutely must have continuous deployment of both site code/content and model updates then EF migrations might not be the best tool to get started with as you will find it very restrictive OOTB for this scenario.