How to handle data changes in Blue/Green deployment technique?

Question

I have studied this article about Blue/Green deployment, then some more googling introduced me to this article about Canary Release. I have this ambiguity : what will happen to databases? how we should make them synchronized? i have two possible scenarios in mind :

• imagine there are two separate databases one for each environment
  (green and blue) at the time that blue is active, new records will be inserted into it's database and green is not aware of these changes
  unless we provide a trigger like mechanism(or any other mechanism) to update the green database.
• second scenario suggests that we share a backward compatible database between two environments, but backward compatibility is not so easy
  when dealing with databases, we have to publish database changes
  before publishing the application.

there may be third scenario, implement a Blue/Green deployment for databases inside the main Blue/Green deployment.

what do you think is the better solution and why? do you suggest any other practice or well known pattern ?

thank you

Answer 1

I have personally only worked with the backwards-compatible databases approach. The main benefit is that it well understood and works for a wide variety of deployment types, including canary and blue-green; I have used that approach even without the benefit of a blue-green deployment strategy (the mundane rolling deployment to all servers, which is essentially a fast canary deployment). Having to deploy database changes before application releases is common to several deployment strategies not that burdensome compared to the need for complicated triggering or mirroring mechanisms between different database versions.

Your third scenario also falls into the trap of needing triggering or mirroring between the database slices as well. In RDBMS terms, this is typically unsupported or completely impossible because there is only master database and all other instances do not accept write operations. The net effect of this is that the version of the master instance is the de-facto version of the whole database.

Certain No-SQL databases do not fall into this trap. For instance, MongoDB will happily allow multiple, different versions of document schemas in the same collection. This allows your application to be informed of the data version and handle the documents differently. However, MongoDB is not appropriate for all applications (just like an RDBS is not the right data store for certain types of data).