Deploying new functionality or version of a software always have the risks of introducing bugs, downtime and chaos. I usually get shivers during deployments J Some of the things that can go wrong:
- Application failures
- Capacity issues
- Infra failures
- Scaling issues
If you are practicing continuous delivery correctly, releasing to production is not always another deployment. You need to measure risks, think of what can go wrong, coordinate and communicate while going to production.
There are low risks techniques to release software which are as follows:
- Blue green deployment
- Canary releases
- Dark launching
- Production immune system
- Feature toggles
Blue green deployment is a release management technique to minimize downtime, avoid outages and provides a way for roll back during deployment.
Initially you need to have at least two identical setups.
For a setup of two identical environments, one is called blue while the other is called green. That is why this release technique is called Blue/Green Deployment. Companies like Netflix call this technique Red and Black deployment. I have also heard; it is called A/B deployment. Regardless of the name, the idea behind it is pretty straightforward.
You can always have multiple identical setups in geographically distributed data centers or within the same data center, also on cloud.
A load balancer or a proxy is a must to achieve this process.
While deploying, you need to cut off the traffic from one setup and have the traffic go to other setup(s). The idle environment is called blue and the active setup is called green. You do the deployment to blue environment, once the deployment is done, you do the sanity checks and tests, once the environment is healthy, you can take the traffic onto it. If you see any problems, with the blue setup, you can always roll back to the stable version.
The best part of this practice is that deployment happens seamlessly to your clients.
This technique can eliminate downtime due to application deployment. In addition, blue-green deployment reduces risk: if something unexpected happens with your new release on Green, you can immediately roll back to the last version by switching back to Blue.
If you have multiple data centers:
Initiall two data centers are active, serving to clients.
Take the traffic off from Cluster 1 and let it go to Cluster 2. Do the deployment to Cluster1, check if deployment is successful, run the tests.
Take the traffic off from Cluster 2 and let it go to Cluster 1, your new version is now live. Then do the deployment to cluster2, check if it is successful, test it.
Have the traffic go to both cluster by routing the traffic to both data centers.
Data Store replication: If your application is using any data stores across different region or data center replication becomes crucial. Database and schema migrations need to be implemented. This can be a uni- directional or bi-directional replication depending on the needs.
However, if you are using a single data store that is feeding applications, database schema changes need some attention as well.
If your app uses a relational database, blue-green deployment can lead to discrepancies between your Green and Blue databases during an update. To maximize data integrity, configure a single database for backward and forward compatibility.
Service Contract changes: Yet another challenge is updating service contracts while keeping the applications up and running.
Cache warming up: After deployment warming up caches can take some time.
Session Management: Session management strategy is crucial and can be problematic during deployment. Using a dedicated session storage will help a lot while doing blue/green deployments.
Today, we have docker, kubernetes and cloud of course. All these platforms also supporting and embracing blue green deployment.
Read more at martin fowler