When there's software, there are deployment strategies. Organizations develop various plan - of - action and follow different deployment methods, ultimately aiming to achieve their constructive business goals. However, we have a few most talked about DevOps strategies that shoot the automation levels to their next step. We shall have a brief explanation of different deployment strategies here.
The Recreate Deployment strategy works almost like a traffic signal. It stops the ongoing application's version deployment, deploys a newer application version and changes the course of the application. This diversion towards the latest version is lead by the Load balancer. Depending on the size and type of application, this technique takes about a few minutes and is simple to handle also renews all the applications' state.
The deployment strategy follows an array approach in deploying a newer version. For example, if a Kubernetes has more than 2 clusters operating, a new version of a Cluster is deployed by shutting down the instances of previous versions one-by-one. Hence it is also termed as Rolling Update Strategy. Since the steady release of instances in the version, it is easier for applications to take care of data rebalancing.
Parallelism plays a crucial role in the Blue/Green deployment. An up to date version will be created in parallel with the old one. The instances of the cluster are processed for further testing. Once the testing results scores a top card, the previous version is replaced by the new one.
The production deployment carries off a gradual rollover from an older to a newer version of the cluster, when we have no tests performed. Canary deployment pays attention to the performance, though the slow re-roll of the instances is a factor.
Are you looking to test the application for mobile users? A/B Deployment strategy would serve as a better choice. We can refer to this more like a sister of Canary deployment, yet has its uniqueness while deploying the mobile apps and conditionally differ in version bottleneck concerning geolocation, language, browser version operating system, etc. Analogous version deployment and an absolute command over the bottleneck distribution are eye-catching advantages. However, we do have a rough time troubleshooting the errors and effective load balancing.
As the name goes, one deployment version shadows the other. When we have an incoming request for the first version, the traffic can be redirected to the second version. Sounds cool for a new feature deployment and performance testing right? Nevertheless, there's no deployment happening until the stability and performance is met. The complexity of the setup impacts the wallet and also requires a mock service in certain cases.
Choosing the right deployment for your task requires a thought. In common scenarios, during staging or development, Recreate or Ramped deployment is recommended. While during the production, Ramped or Blue/Green deployment is a good choice. If you want to migrate a new database technology, then Shadow deployment can check your priority list. In case of lacking test, Canary or A/B deployment can be your alternative.