Skip to content

Rolling Deployment

Overview

A Rolling Deployment is a software release strategy where new versions are incrementally deployed across servers or instances, one at a time (or in small batches), until all are updated.

Unlike blue/green or canary deployments, rolling replaces the current version in-place without duplicating infrastructure.

How It Works

Imagine you have 5 servers (or containers) running version 1 of your app:

  1. Take one server out of the load balancer.
  2. Deploy version 2 to that server.
  3. Put it back into the load balancer.
  4. Repeat for the next server… until all are upgraded.

This minimizes downtime and avoids overloading the system.

Advantages

  • Zero downtime (if load balancing is used properly)
  • Fewer resources needed than blue/green (no need to duplicate entire environments)
  • Automation-friendly and works well with Kubernetes, App Service, etc.

Drawbacks / Risks

  • Rollback is slower and more complex — you need to roll each instance back manually.
  • Incompatibilities can occur if some users hit the new version and some hit the old.
  • Stateful applications or shared databases may introduce race conditions or errors.

Common Use Cases

  • Web applications deployed across multiple servers or containers
  • Microservices with stateless, independently deployable components
  • Container orchestrators (e.g. Kubernetes) where pods can be replaced incrementally

Example in Azure

Azure App Service

  • Azure handles rolling updates automatically during deployments.
  • You can configure deployment slots if you want more control or traffic shifting.

Azure Kubernetes Service (AKS)

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

This YAML config ensures pods are updated gradually, maintaining availability.

Conceptual Analogy in C#

While rolling deployment isn’t coded in C#, the idea is that you’re sequentially updating app instances, e.g.:

Instances: [A, A, A, A, A]
Rolling update: [B, A, A, A, A] → [B, B, A, A, A] → ... → [B, B, B, B, B]

Comparison with Other Deployment Patterns

Deployment Type Traffic Routing Rollback Ease Resource Usage Risk
Rolling Gradual replacement ⚠️ Moderate ✅ Efficient ⚠️ Medium
Blue/Green Full switch (all at once) ✅ Very easy ❌ Duplicate needed 🔽 Low
Canary Gradual exposure (parallel) ✅ Easy ⚠️ Medium 🔽 Low
Shadow Duplicate traffic, no impact N/A ❌ High 🔽 Very low

When to Use Rolling Deployment

Use when:

  • You want minimal downtime.
  • You can tolerate short periods of mixed versions.
  • Infrastructure cost is a concern (e.g. no duplicate environments).

Avoid when:

  • Your system is stateful or tightly coupled to a shared database schema.
  • Rollback speed is a priority.
  • You need full test coverage of the new version before releasing.

Summary

Aspect Description
What it is Gradually replacing old instances with new ones
Risk Level Medium — good availability but rollback can be complex
Cost Low — reuses existing infrastructure
Rollback Harder than Blue/Green or Canary
Azure Support Native in App Service and AKS; use with deployment slots or rolling configs