DevOps best practices and cases

How to choose a deployment strategy?

Deployment strategy is the way of updating or changing the application. The main aim is to make changes smoothly and stably without downtimes. Generally, the choice of deployment strategy depends on business tasks and the expected impact on the system and the end-user. There are six types of deployment strategies: 
  • Recreate – Version A is terminated and version B is rolled out.
  • Ramped (rolling-update) – Version A is slowly replaced by version B
  • Blue/Green – Version B is released alongside version A and then traffic switches to the new version.
  • Canary – version B is released to a group of users for testing and then roll out to all users 
  • A/B testing – version B is released to a group of users for testing and then traffic slowly changes to version B
  • Shadow – version B receives a duplicate of real traffic from version A and doesn’t give a response.
So these are six major deployment strategies, now we will analyze them and demonstrate the pros and cons of all approaches. It is possible to test all these strategies on Kubernetes, it gives vast opportunities for application deployment. 


Recreate strategy is a simple shutting down of version A and the release of version B. This technique means the presence of downtime between the old version is off and the new version is booting. Shutdown duration depends on both these actions.


  • Easy to setup
  • No need to maintain two versions of the application


  • Downtime impacts the end-user and depends on the processes of scaling down an old version and scaling up a new version.


Ramped strategies mean that version A is slowly replaced by version B. Instances with version A shut down one by one and instances with version B are rolled out. Usually with a pool of instances with version A connects an instance with version B. When everything is ready, the load balancer transfers traffic from instance A to instance B. When everything is good, instance A is shut down. This procedure repeats until all instances with version A will be replaced by instances with version B.


  • Easy to configure
  • Slowly release among instances
  • No downtime
  • Suitable for applications that can track the state and rebalance the data


  • Rollout/rollback can take time
  • Supporting multiple instances with various version of an app requires specific skills
  • No traffic control


Blue/Green deployment differs from ramped deployment strategy. Version B rollout on the same number of instances as version A and after all tests are committed, traffic switches to version B by the load balancer.


  • Instant roll-out
  • All instances change at once
  • No possibility of versioning issue


  • Expensive as it requires to double the resources
  • All tests have to be done before launching


Canary deployment means gradually shifting a load from version A instances to version B instances. In most cases, traffic switches gradually, for example, 10% to 90%. This technique will be useful when there are not enough tests or developers are not confident about the stability of the version.


  • Version release for a group of people
  • Fast rollback
  • Convenient for error monitoring


  • Slow rollout

A/B testing

A/B testing is rather about decision making and planning than about deployment strategy. It is a similar canary deployment strategy. During the A/B testing part of the traffic, routes to set of instances with a new version of an application under particular conditions. It allows controlling all processes and making testing on the production environment. Also, it is a good tool for collecting statistics and user feedback. It can be used for testing various versions of an application and roll out one that more suitable for customers.
There are a set of parameters that can be used to distribute traffic:
  • Geolocation and localization
  • Technological features (screen size, operating system, browser version, etc.)
  • Language and many others.


  • Multiple versions run simultaneously
  • Full control over the traffic
  • Advanced testing on a live environment


  • Requires advanced load balancer
  • Requires advanced monitoring because it is hard to troubleshoot errors for various sessions


Shadow deployment means that version B releases alongside version A, but do not receive direct traffic. However, developers replicate traffic from version A, which can be used for performance testing. The rollout of the application performs only when all tests meet the requirements. This technique is complex in setting up, for example, traffic from the shopping card can create a situation when a customer will pay twice.


  • Performance testing of an application without real traffic
  • No impact on user
  • Deployment commits only when all test meet requirements


  • Expensive, as it requires double the resources
  • Complex to setup
  • Not a true user testing and feedback
  • Requires services for mocking data

To sum up, there are many ways to deploy an application and you have to choose, based on budget and requirements. For production, ramped and blue/green is the best choice, but propper testing is also important. Also, blue/green and shadow testing can influence a budget because requires additional resources. When you doubt your testing processes, you should use A/B testing, canary deployment, and shadow deployment. When it comes to testing with some specific parameters, A/B testing will help. Shadow testing can help in testing some important things such as migration to new database technology. So, deployment strategies provide vast opportunities for testing and adjustment. Using this table you can choose the right strategy:

And if you want to test them we recommend you to use Kubernetes. If you do not know what it is to doubt whether you need to use it, read our article.

If you have any questions about your deploy strategy or building DevOps in your company contact us and we will discuss it deeply.