[shoo]

Great question. I don't know the details of how database schema changes were deployed, I only worked on the easy stuff - stateless web services.

Exactly as you say, there is a time window where both the old and new system write to the same data store. Both old and new systems, and the details of the deployment, need to be designed to tolerate this. Even if there is no change to the database schema, you need to think through what will happen if the old version of a component reads data written to the database by a newer version of that same component, or vice versa. Similar considerations if you need to roll back to the old version after the new version has run in production for a few hours, but the newly written data is still there. This can all be planned out and tested in staging.

I don't think this is unique to the blue / green deployment pattern. If you did a rolling deployment to upgrade app servers in a pool behind some customer-traffic facing load balancer, there would be a time window when both old and new versions of your app servers are all attached to your database. Same fundamental problem.

[rvdginste]

We intend to do something similar. The users get a pop-up in the front end when a new version is available and are asked to load the new version, but they can keep on using the old version for a while. The length of the time window does not really matter that much: whether it is 5 minutes or several hours, the issue is the same. Regarding the database upgrades, I believe that if you really want to, you can split up a not-backwards compatible upgrade into multiple upgrades that are each one on one backwards compatible. But that is extra work and like you said you really have to think those things through for every change you roll out. So I think the extra effort is not always worth it and also I wonder how other people are approaching this.