Azure Web App deployment slots with database migration

Question

I'm currently running a webApp with several deployment slots (eg dev, staging, production). Every Slot is connected to a database (db_dev, db_staging, db_production). I want to deploy to the staging slot and then switch with production. How do database migrations fit in here?

I mean, if i deploy a new build with db migrations to staging the db_staging gets updated. What happens if I switch the slots? Do the migrations get applied to db_production? What about downtimes?

From my understanding only the URLs are switched, so after the switch the app in the staging slot would point to the db_production? That does not make sense.

I could deploy to the staging slot and point to db_production (with migrations), but then the db would be updated and could possibly break the app in the live slot.

Answer 1

Instead of hard coding the connecting string in your source code, put them under the connecting strings section of your app service settings and access it as an environment variable. It's not only safer as it will allow you to have just one code for any environment and by checking the setting as a "slot setting" no matter if you swap or not, for that slot, the configuration remains fixed.

More info here:

https://azure.microsoft.com/en-us/documentation/articles/web-sites-configure/

Update :

In the case of a database update, ie, necessary scripts that need to be run in order to update the database schema for the new app version, you can use the applicationInitialization section of your web.config. Usually used to warm-up the app, but should work for your case as well.

<system.webServer>  
  <applicationInitialization >  
    <add initializationPage="/init-script.php" hostName="xxxxxx.azurewebsites.net"/>  
  </applicationInitialization>  
<system.webServer> 

The AppInit module will wait until this code completes before finishing the swap process which is basically allowing production traffic to the app. Basic logic would be checking if the database is running the expected version and if not some other logic would be executed in sequence.

Answer 2

I have been pondering this too, and as far as I can see the only sensible process is as follows:

1. Stop Prelive stites
2. Clone live DB back to a new staging DB
3. Run scripts to make data safe (clear information which may contact real users etc)
4. Change staging slot sticky connection string to point at this database
5. Run DBUP aganst staging DB (now an upgraded version of live-ish)
6. Deploy to staging slot
7. Restart prelive sites
8. Test staging until satisfied
9. Backup live DB
10. Run DBUP against live (if they are non-breaking changes, site can stay up)
11. Swap live and prelive slots
12. Check live

If you can keep your db updates non-breaking, then rollback can be simple as swapping the slots back. If not, you are back in the familiar pain of rollback scripts or restoring snapshots.