Techie BabajiLearn to Code. Build Real Skills.
DevOps · Operations

Deployment Strategies

How you replace the old version with the new one decides whether users notice — and how fast you can back out.

Advanced 5 min Lesson 25 of 30
Before you start:Release Pipelines
0/30 in DevOps
On this page · 5 min · Advanced

On this page

  1. Learning objectives
  2. Explanation
  3. Code example
  4. Step by step
  5. Real-world use
  6. Common mistakes
  7. Best practices
  8. Remember this
  9. Practice exercise
  10. Mini quiz
  11. Related topics
  12. My notes
Reading time
5 min
Difficulty
Advanced
Updated
Oct 29, 2026

Related tutorials

Interview questions

Learning objectives#

  • Compare recreate, rolling, blue-green and canary
  • Choose a strategy for a given app
  • Use feature flags to separate deploy from release
  • Know the database implications

Explanation#

Recreate: stop old, start new — simple but has downtime.

Rolling: replace instances gradually (Kubernetes default) — no downtime, both versions run briefly.

Blue-green: run the new version beside the old and switch traffic at once (App Service slots) — instant rollback, double capacity.

Canary: send a small percentage of traffic to the new version, watch metrics, then increase. Feature flags turn features on without redeploying.

Code example: Choosing a strategy#

TextChoosing a strategy Illustrative
Strategy     Downtime   Rollback speed   Extra cost   Good for
Recreate     Yes        Slow             None         Dev/test, batch jobs
Rolling      No         Medium           Low          Most stateless APIs
Blue-green   No         Instant          2× briefly   Critical web apps (App Service slots)
Canary       No         Fast             Low          High-traffic services, risky changes


Database rule for all of them: expand → deploy → contract
(add new columns first, deploy code that uses both, remove old columns later)
Expected output
Most teams start with rolling or blue-green; canary adds safety for high-traffic systems.

This example is illustrative. Copy or download it and run it in your own environment; the expected output is shown above.

Step-by-step explanation#

  1. Decide whether brief downtime is acceptable.
  2. Weigh rollback speed against extra capacity.
  3. Make database changes backward compatible.
  4. Use feature flags for big features.

Real-world use case#

A payment service sends 5% of traffic to a new version for 30 minutes; error rate stays flat, so it rolls out to 100%.

Common mistakes#

Breaking database changes during a rolling deploy

Old and new versions run together. Use expand/contract migrations.

Canary without metrics

A canary is only useful if you compare its error rate and latency.

Best practices#

  • Default to rolling or blue-green
  • Expand/contract database migrations
  • Automate canary analysis
  • Feature flags for gradual releases

Remember this#

Rolling = gradual. Blue-green = switch. Canary = small % first.

Deploy ≠ release (feature flags).

Expand → deploy → contract.

Practice exercise#

Your task: Which Azure App Service feature implements blue-green deployments?

Show solution
Text Illustrative
Deployment slots: deploy to staging, then swap.

Mini quiz#

Deployment Strategies quizMultiple choice Question 1 of 1

Which strategy sends a small share of real traffic to the new version first?

Score so far: 0/0

Want more? Practise all DevOps MCQs · DevOps interview questions

My notes#

Saved in this browser.

Progress is saved in this browser. Sign in to sync.