1

Let us say blue and green app services share the same database instances and you can use slots for swapping the applications. How would you handle the schema-breaking changes, as some users may be about to post a request that would not work with the new schema?

From my understanding, it looks like you always have to write backward compatible code that would work in both cases to handle the schema changes, which does not look much ideal to me.

Ozmen
  • 43
  • 3
  • What database are you using? Azure SQL? Is there one tenant per database, or might there be more than one tenant per database? – Rob Reagan May 25 '17 at 19:13
  • I am using Azure SQL and there is one tenant per database. – Ozmen May 26 '17 at 00:03
  • "Best Practices" is subjective and opinion-based, and isn't a good fit for StackOverflow. Perhaps you can tell us specific issues you are struggling with in your blue-green deployment process, and then folks can make recommendations. – Rob Reagan May 26 '17 at 00:11
  • Thanks for the heads up Rob, I have edited the question – Ozmen May 26 '17 at 00:23

1 Answers1

0

There is no magic bullet for rolling back Azure SQL schema changes. Unfortunately you will have to create a script to deploy new updates to your database, and one to roll changes back if things do not go well if you choose to do so. There is a tool called Elastic Jobs that will help you execute scripts across one or more databases in an elastic pool.

Rob Reagan
  • 7,313
  • 3
  • 20
  • 49