I’m currently configuring an environment for a web site. As I’m using azure, I’d like to use deployment slots in order to ensure that users won’t get any downtime. While I understand the goal of deployment slots, I have difficulties to understand how they could be usable in my case.
Basically, the site is using a database that will evolve as the times goes. In other words, most of my releases will alter the schema of the database and I can’t ensure that it will always be backward compatible (indeed I might delete columns or something).
Therefore, there are two solutions in my mind . Either both DS will share the same database or they use different ones. However, if they share the same database, after the deployment is executed in the staging DS, it can be that the production one start failing (because it’s referencing a deleted column for example). So I can’t use DS the way.
Using two separate databases seems to be a viable option... if they are synchronized. Indeed, if the db of the staging db is only there to validate a deployment, I can’t swap the site to this DS while production DS is updated, as the data of this DB won’t be up to date. Therefore I need to ensure that data are in sync BUT that when the staging gets updated, this sync is somehow paused as the schema won’t be the same anymore...
All the article I read talk about DS without really mentioning the database issue, so I don’t really understand how it is supposed to work. Can some enlighten me a bit please ?
