Recommended ways to deal with database migrations while doing a swap using deployment slots

Question

I am trying to understand the use of deployment slots for hosting my web app using the Azure app service. I am particularly confused with the ideal ways to deal with the database while the swap is performed. While maintaining two database versions seems like a solution, it adds the complexity of maintaining data across multiple databases to make them consistent. What are the recommended ways for dealing with database schema and migrations while using blue/green deployments and in particular deployment slots?

Answer 1

Ideally you'll stage / production would share the same database, so it would not be an issue.

But if you have more slots, then you'd better also work with different databases and handle migrations during the release phase

Answer 2

We've worked through various solutions to this problem for a few years. There's not a toolset that provides a magic bullet for all cases. There are a few solutions:

Smaller databases/trivial changes

If it is possible to execute a migration script on a database that will complete in a second or two, and you can have an easy fallback script, you can execute the script concurrently with the swap. This can also be automated. But it's a higher stress situation and not one I'd recommend. This can even be done with EF Migrations.

Carefully ensure database compatibility between versions

Since we're dealing with a few hundred GB of data that cannot go down, we've just made it a rule that the database has to work with both versions of our application. It's not as awful or impossible as it sounds. For example, net new tables and fields can oftentimes be added before you even perform the swap. We test rollback between versions as part of our QA. If some fields need to be dropped, we wait until after the new version has been deployed and burned in, then run another script to perform the drops after we're sure we won't need rollback. We'll create new stored procedures when one needs to be upgraded so that the new version has its own. Example: sp_foo and sp_foo2.

We've had a lot of success with this strategy.

Answer 3

Slots are a feature specifically for App Services and not for DBs, if you want to use a specific DB with a specific slot then you setup the slot like this: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots

Now when using Slots and swapping it also swaps App Configurations\Settings, and in App Settings you can have two DB connections strings but each with its own slot name and setting enabled. You can see it has been shown in this example here as well: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#swap-two-slots