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. At that time everything a customer needed was noted down one time, and then we used to create, test, and deploy our software entirely, with no change after that. If a problem occurs on the server or any update is needed, the whole system is made from scratch and switches users to the new server after a long period of downtime. 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 immediately, 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 redirect the entire traffic to the Green 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 canary bird was historically used in mines to detect dangerous gases. Similarly, in a canary deployment, only a small percentage of users are initially redirected to the new server or application version. The percentage is then gradually increased as confidence grows.

In a rolling update, the servers are updated gradually while all users continue to access the updated servers as they are replaced. In contrast, a canary deployment gradually shifts users to the new version while the old version remains available for the remaining users.

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.