4

I'm currently running a webApp with several deployment slots (e.g. 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.

user3838018
  • 185
  • 1
  • 11

2 Answers2

4

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.

Kinetic
  • 542
  • 5
  • 15
2

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.

Bruno Faria
  • 4,740
  • 3
  • 20
  • 27
  • 1
    I understand that every slot has its own configuration, but what about db migrations? How do they apply? Let's say I deploy to staging with migrations, so staging db gets updated. How does production db gets updated? And how do I access the variables in my code? Currently I use web.config. Thanks in advance – user3838018 Jul 28 '16 at 13:57
  • 1
    There's no automatic way since it's a custom logic you have to implement for your app. I posted an update with a possible workaround although I never used for this purpose it should work. – Bruno Faria Jul 28 '16 at 14:16