Azure Web App deployment slots with database migration Azure Web App deployment slots with database migration azure azure

Azure Web App deployment slots with database migration


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 canstay 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.


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.

enter image description here

More info here:

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

Update:

In the case of a database update, i.e, 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.