Let’s start with what is Deployment Strategy.

Running any software on server requires a set of steps to follow as per the software's need, end-user’s usage type and goal of the production team. Now deployment steps may vary as per these scenarios. The different steps to follow are called Deployment Strategies.

Some History

Previously we used to follow the Waterfall model for SDLC. On that time everything a customer needs noted down single time and then we used to create, test and deploy our software entirely and no change after that. If problem occurs on the server or any update is needed the whole system is made from scratch and switch users to the new server after a long period of down time. Now this is a deployment strategy called Big Bang Deployment. Now these days this niche step of deployment is replaced with,

Blue Green Deployment

In this type two Deployment environment is created. One will be live where users are interacting and other will be on hold for testing and initial deployment. The live environment is called Blue and Testing one is called Green. The Colour Terminology doesn’t matter the operations performed on the environment matters. Now after Successfully testing the Green one the users will be redirected on that. Now what to do with the Blue Environment? We do not remove it, rather we keep it for some time as per need. It can be Days or for few hours only. If any problem occurs on the Green environment, we will again rollback to the Blue one, else we stay on the Green one and after Successfully passing the monitoring time the Blue environment will be removed.

Rolling Deployment

In Blue-Green strategy we are redirect the entire traffic to the Green one at once. This creates a limitation to control the traffic and no instant backup if user is getting problem on redirected. In Rolling update, we solve this issue by updating and testing the environment on by one and redirect the traffic gradually on them like round robin algorithm. This takes some more time but improves the reliability and any time if problem occurs, we can stop the redirection process. This creates a much more user-friendly experience.

Canary Deployment

A single Canary Bird is used to examine the Mines back in those days. We use the similar process by redirecting only few users to the new server initially. And increase the user percentage gradually. In Rolling update, we are updating the servers gradually but here we are shifting the users gradually to the new server.

A/B Deployment

This Deployment works like Canary Deployment because it also redirects traffic gradually to the server. But we can control the users by dividing them as per Geographic Location, Language, and Operating System types. The main part involves the Comparison of the two servers in A/B Deployment Strategy.