Summary
Most of what is written about Blue/Green deployment either restates the definition or walks through a hello-world service that has nothing to do with the field. I wrote this article to list what actually has to be decided before a Blue/Green pipeline can succeed.
The first decision is scope. Blue/Green applies to a component, and to a version of that component, not to a whole environment. Duplicating the entire stack, load balancers, database, cache, storage, frontend and backend in one pipeline is an anti-pattern that leads to unmanageable complexity and desynchronised data; duplicating a Kubernetes cluster for it is out of the question. Different components can even use different strategies: Blue/Green or rolling update for the database migration, canary for the backend.
Then come the questions that tutorials skip. Whether the first deployment and later updates share one pipeline. Backward compatibility of everything persistent, schemas, files, properties and event topics, without which rollback is impossible; delete logically first and physically a few versions later. Sessions stored outside the application, in a cache or a database, so that the switch does not log users out. Who decides to decommission Blue, and on what trigger, given that most projects rely on manual business acceptance rather than complete functional tests. And how to fall back to Blue while both environments still exist.
None of these questions is technical alone. They call for business, development and operations to agree on the requirements, component by component, before anyone writes a pipeline.
Key ideas
- Blue/Green applies to a component and its version, not to an environment; mixing every concept in one pipeline is an anti-pattern.
- Every deployment strategy but recreate keeps the service up; what Blue/Green needs in return is a rollback path that still exists.
- Persistence must stay backward compatible, schemas, files, properties and topics alike: delete logically now, physically a few versions later.
- Keep sessions outside the application, in a cache or a database, so that switching versions does not disconnect anyone.
- Decommissioning Blue is a decision of business, development and operations together, on a trigger they choose: automatic, manual, event or time.
Why I wrote this
The literature offers many articles that put forward the definition of Blue/Green or explain very briefly the implementation of a hello-world service disconnected from the reality of the field. The objective of this article is to bring out the elements to identify in order to succeed with this strategy.