DevOps · deployment

Deployment strategies

Congratulations on building a fancy new thing, it’s brilliant, now it needs to be put somewhere so the rest of the world can enjoy it too.

There is one thing that you need to be aware of, and that is that there is an existing version of your thing already out and being used by the world.

The way that you deploy your new version depends on a few variables, that only you can answer.

There are three basic strategies:

  • Canary
  • Rolling/Incremental
  • Blue-Green

It’s bad practice to say that one is better than all others, because that’s not the case. You use the right one for the right usecase.

Canary

A Canary deployment is where a single instance of the new version is pushed to prod. It is treated the same as the existing instances (of the previous version) and will show very quickly if there are any problems with the new version.

Once it’s established that the canary version is working as desired then one of the other two deployment strategies can be implemented to replace the rest of the old version of application left out in production.

Pros

  • Lower risk - only a small number of requests are affected by the change.

Cons

  • Multiple versions of the application in production.

Rolling/Incremental

A rolling deployment strategy is where existing instances of one version of an application are slowly replaced by the new version, perhaps as the older versioned instances finish working on their current tasks.

Pros

  • No interruption to service availability
  • If the new version has problems they can be spotted before the old version has been removed, allowing a rollback if needed with only limited numbers of users affected.

Cons

  • Multiple versions of the application in production.

Blue Green

A Blue Green deployment is where all of the old versions are replaced in one fell swoop with a set of the new versions. Usually the new versions are all created in their own environment and ready to go as soon as the switch is flicked.

Pros

  • Only one version of the application out in production

Cons

  • Downtime - there has to be time put aside for the changeover to take place. There’s no way that requests can be in progress in the old versions because they will die when the old versions are switched off.

Note: Rolling back is easy with Blue Green, with the condition that the deployment wasn’t a breaking change.

It should be clear that continuous deployment environments aren’t suited to a blue/green strategy (although it’s not impossible).

Published:
comments powered by Disqus