21. Deployment strategies

Table of Contents

A. Naive/Basic Deployment

All nodes within a target environment are updated at the same time with a new service or artifact version.


  • Simple, fast, and cheap


  • Riskiest and does not fall into best practices

B. Multi-service Deployment

All nodes within a target environment are updated with multiple new services simultaneously.


  • Simple, fast, cheap, and not as risk-prone as a basic deployment


  • Slow to roll back and not outage-proof

C. Rolling Deployment

All nodes are incrementally updated with the service version in integer N batches.


  • Relatively simple to roll back, less risky than a basic deployment, and simple to implement


  • Updated in batches, rolling deployments require services to support both new and old versions of the service.

D. Blue/Green Deployment

  • Blue - staging environment
  • Green - production environment

Utilizes two identical environments, with different versions of an application or service. Quality assurance and user acceptance testing are performed in the staging environment.

User traffic is shifted from the green environment to the blue environment once new changes have been testing and accepted within the blue environment.


  • Simple, fast, well-understood, and easy to implement
  • Rollback is straightforward
  • Not risky


  • Replicating a production environment can be complex and expensive
  • An outage or issue could have a wide-scale business impact before a rollback is triggered

E. Canary Deployment

Release an application incrementally to a subset of users. All infrastructure in a target environment is updated in small phases (2%, 5%, 10%, …, 100%).


  • Test production with real users
  • Fast and safe to trigger a rollback to a previous version of the application


  • Scripting a canary release can be complex: manual verification or testing can take time, and the required monitoring and instrumentation for testing production may involve additional research.

F. A/B Testing

Different versions of the same service run simultaneously as “experiments” in the same environment for a period of time.

  • Experiments are controls by some mechanism
  • Commonly, user traffic is routed based on specific rules or user demographics to perform measurements and comparisons
  • Primarly focused on experimentation and exploration


  • Standard, easy and cheap method


  • Experiments and tests can sometimes break the application
  • Scripting or automating AB tests can be complex