17

I'm planning to push a new web application to an Azure Web App Service (former Azure Website). I'd like to make use of the deployment slots to be able to test my deployment before pushing it to production. That's all fine as long as there is no DB schema change require. But if there is a schema change I can't have two software versions operating on the same db version. Since I'm using EF Migrations, the push to the staging slot would instantly result in a DB update to the latest version.

So my question is, whether there is any use of deployment slots when a db migration is required?

How is it done for large SaaS providers. Are they performing a DB migration instantly with the new version? That would surely cause some downtime.

I can only think of rather complex solutions to this problem, is there anything simple?

Improve this question
5
  • So you don't have a dev database?
    – JeffO
    Commented Apr 1, 2015 at 18:04
  • Yes, we have a dev and QA system. The system described above is for production purposes.
    – Sam7
    Commented Apr 1, 2015 at 22:21
  • @Sam7 did you manage to find a solution to this issue? Cheers
    – WestDiscGolf
    Commented Apr 27, 2015 at 9:09
  • I'm afraid not. We're currently testing migration changes in a separate environment.
    – Sam7
    Commented Apr 28, 2015 at 4:22
  • @Sam7: i think you can manage this by a separated .config-file with an own connection string to your db. but you are right, when you deploy from stage to production, the benefit of a rollback doesn't work anymore. the db changes will apply instantly. i'm curious for a solution in the near future...
    – Roger S.
    Commented Oct 13, 2015 at 12:23

2 Answers 2

Reset to default
3

Zero-downtime releases using Azure App Service slots and a single database shared by Staging and Production are possible - but you need to make sure that all database changes are backwards compatible, such that the current and new versions of the web app can run simultaneously in the Staging and production slots.

Some rules that ensure this works:

  • Any new database columns should be nullable or have default values
  • Renaming columns is not permitted
  • Dropping columns is not permitted

When you do need to make destructive changes, such as renaming or dropping columns, you need 2 releases to do this:

  1. The new version of the web app should be released, which removes the dependency on the renamed/dropped columns
  2. An additional release is made that performs the destructive changes

While this sounds a bit complicated, in practice you likely won't be making destructive changes very often.

Improve this answer
0

have you looked at the slot-specific configuration items? Under WebApp/Settings/Application Settings you can specify settings for the web app but also define whether it only applies to this slot.

You could, therefore, have a slot-specific connection string for your staging slot and apply the migration on swapping slots too.

Improve this answer
1
  • 2
    That goes against my idea of having the staging site working off the exact same dataset (-> database) as production.
    – Sam7
    Commented May 12, 2016 at 6:02

Not the answer you're looking for? Browse other questions tagged or ask your own question.