Introduction
One of the activity that every developer wishes, is hassle free application deployment so that they don’t have sleepless nights due to deployment failure ππ. Specially in the large teams and business units, when there are hundreds of microservices, the deployment task has to be carried out very cautiously. If the deployment fails due to any reason, be it wrong application configuration or any other issue, we should have rollback strategy in place, so that application can be brought back stable state.
Traditional application Deployment
In the traditional deployment, if there was any deployment failure, the previous stable version of the application was being deployed. Sometimes rollback is not easy because we need to perform all the activities from scratch. In the worst case the application is unavailable for long periods of time.
In order to avoid all the havoc, we need to have proper deployment strategy in place. In this post we will discuss one of the many deployment strategies i.e. Blue Green Deployment.
Blue Green Deployment
A Blue Green deployment is a deployment strategy which consists of two live production environments at the same time that are identical to each other. In this deployment strategy, the role of live production can either be Blue or Green. Lets consider Blue as the current production application present in production, and green as the new version that is to be deployed. The main goal of this strategy is to reduce the downtime of the application so that no business user is impacted.
Blue environment consists of the live production application. After adding a additional features to your application you deploy it to the Green Environment. In order to test if existing features as well as the new features are working fine, you allow some part of the applications traffic (1% or any criteria of your business domain say user Id) to the green environment. After successful testing either gradually increase the traffic or switch over the Green environment as the live production environment. In case of any failures you can rollback to the previous stable version i.e. Blue.
When you have new set of features ready for your next release, you switch from green to blue like you did from blue to green earlier. That way both green and blue environments are playing the roles of live and rollback versions.
From the database standpoint, the deployment strategy can be tricky. The priority should be given to database schema changes (if any) first which supports the Blue as well as Green version. The rollback version should be tested first, if everything is fine then deploy the new version of application. If testing was successful with the new production version, then the next task would be to remove the database support for the old version of the application.
Blue Green deployment on Pivotal Cloud Foundry(PCF)
Lets talk about blue green deployment in Pivotal Cloud Foundry. CF Router plays a major role of switching the traffic between Blue and Green versions of the application. All we have to do is Map or Unmap the route (URL) to Green or Blue based on the verification done for your application flows.
For more detailed information, you can go over the official documentation by Pivotal.
Blue Green deployment on Amazon Web Services (AWS)
In AWS, there are are components which contribute or work together to achieve Blue Green deployment strategy. For detailed and well explained documentation, you can go over the official AWS blue green deployment guide.
I hope you liked this post. Please do share across the community so that everyone will have a good time learning. Please feel free to comment if you find anything to be corrected in the post.