How to handle database rollback in Azure Deployment Slots?

Question

With the new feature of Azure Website deployment slots' "Slot Settings", we can 'pin' a connection string and app settings to a particular slot. I have set up two slots: production and staging, and verified I can swap between them and point to the correct database. The database is being updated automatically using code first migrations. However, I'm unsure how exactly a "rollback" would (or should) work with the database in this scenario.

For example, consider the following:

• App v1 is running in staging and pointed to staging Db v1
• App v1 is running in production and pointed to production Db v1
• App v2 is deployed to staging, and Code First Migrations updates staging Db to Db v2
• staging and production slots are swapped.
• App v2 is running in production, and production db is updated to Db v2.
• App v1 is running in staging, but pointed at staging db, which is still Db v2

Is there a way to roll the staging database back to v1? If an "emergency" occurred and I had to swap staging and production again, would there be a way to get the production database back to v1? I understand this can be done using Update-Database, but am unclear how to set it up as automated as possible in Azure Websites.

Answer 1

I think you answered your own question. Unless there is a staging db on DBv1 then you would have to manually update your staging database to do the rollback. I do not think there is an automated way of doing this.