Production Deployment Patterns I Have Used: Rolling, Blue-Green, Canary and Zero-Downtime Releases

Why deployment is an architecture concern

A service is not production-ready because it runs locally or because a Docker image builds.

I want to know:

How does the new version enter production?
How do old and new versions coexist?
What traffic sees it first?
What metrics block promotion?
How do we roll back?
What happens to database compatibility?
What happens to in-flight requests?

Across enterprise programs I have worked with deployment flows that move through:

Development
   |
QA
   |
UAT
   |
Production

with Jenkins, static analysis/quality gates, security scanning, database/configuration deployment and controlled promotion.

This article is the overview. Each major pattern has a linked production implementation.

1. Rolling deployment

Rolling is my normal choice for many stateless low/medium-risk services.

v1 v1 v1 v1
 -> v1 v1 v1 v2
 -> v1 v1 v2 v2
 -> v1 v2 v2 v2
 -> v2 v2 v2 v2

It works well only if:

• readiness is correct;
• termination is graceful;
• v1 and v2 APIs are compatible;
• DB schema supports both;
• cluster has enough surge capacity.

Deep dive:

• Rolling Deployment in Kubernetes

2. Blue-green

For a higher-risk release I may keep two complete environments:

BLUE 100% traffic
GREEN 0%

validate GREEN

BLUE 0%
GREEN 100%

The advantage is a very fast routing rollback.

The cost is duplicate capacity and the need to control background consumers/jobs.

Deep dive:

• Blue-Green Deployment with Kubernetes and Nginx

3. Canary

For production evidence I use progressive traffic.

A practical sequence:

5%
10%
25%
50%
100%

I do not promote based only on pod health.

I compare:

error rate
p95/p99 latency
dependency failure
CPU/memory
business success

For booking or auction flows, a business metric is critical because HTTP 200 does not prove the business transaction completed correctly.

Deep dive including Argo Rollouts configuration:

• Canary Deployment: 5%, 10%, 25%, 50%, 100%

4. Feature flags

Deployment and release can be separate.

code deployed 100%
feature enabled 0%

Then:

employees
5% users
selected tenants
25%
100%

Feature flags are also useful as kill switches.

Deep dive:

• Feature Flags for Progressive Delivery

5. Recreate / maintenance deployment

There are systems where a short maintenance window is acceptable and running two versions together is dangerous or impossible.

Then:

stop old
migrate
start new
verify

can actually be safer than pretending zero downtime is mandatory.

I choose recreate only when the business accepts downtime and the rollback/recovery plan is strong.

6. Shadow / traffic mirroring

Before a major migration I can mirror production requests:

real user -> stable response
        \-> new version (response discarded)

This is useful for:

• performance comparison;
• compatibility testing;
• Strangler migrations;
• new search implementation.

The shadow service must not perform duplicate side effects.

I normally mirror reads or sanitize/disable writes.

7. A/B testing is not canary

Canary asks:

is the release safe?

A/B asks:

which product experience performs better?

A/B may intentionally keep two variants for weeks.

Canary should normally converge to one production version quickly.

8. Database expand-contract

Most zero-downtime failures are schema failures.

During rolling/canary/blue-green:

v1 and v2 run together

so the database must understand both.

I use:

expand
deploy compatible code
backfill
switch
verify
contract later

Deep dive:

• Zero-Downtime Database Expand-Contract

9. CI/CD promotion

My preferred enterprise promotion:

commit
 |
build
 |
unit test
 |
SonarQube
 |
security scan
 |
immutable image
 |
DEV
 |
QA
 |
UAT
 |
PROD

The same artifact is promoted.

Deep dive:

• CI/CD: Dev -> QA -> UAT -> Production

10. Rollback versus roll-forward

Application defect with compatible schema:

rollback image

Data migration defect:

often safer to roll forward

I do not promise rollback until I know what the release changed outside the application binary.

11. Deployment observability

Every release should identify its version in telemetry.

service=booking
version=2026.09.01

I compare by version:

error rate
latency
memory
DB errors
external dependency errors
business transaction success

Otherwise a canary cannot be evaluated correctly.

12. Health gates

I use three different questions:

startup  -> initialized?
readiness -> receive traffic?
liveness  -> process needs restart?

None of them replaces synthetic/business verification.

My release decision framework

All deployment deep dives

• Rolling Deployment in Kubernetes
• Blue-Green Deployment
• Canary Deployment 5%-10%-25%-50%-100%
• Feature Flags for Progressive Delivery
• Zero-Downtime DB Expand-Contract
• CI/CD Dev-QA-UAT-Prod with Jenkins and Gates

My production release checklist

1. One immutable artifact.
2. Version visible in telemetry.
3. Backward-compatible APIs.
4. Backward-compatible schema.
5. Readiness correct.
6. Graceful shutdown.
7. Deployment strategy selected by risk.
8. Automated smoke test.
9. Business metric.
10. Rollback or roll-forward documented.
11. DB migration reviewed.
12. Config/secrets externalized.
13. Error/latency gates.
14. Clear release owner.
15. Post-deployment observation period.

Architect's final take

The best deployment strategy is not the most sophisticated one.

A five-percent canary with no useful metrics is less safe than a well-tested rolling deployment.

Blue-green with an irreversible schema change is not truly reversible.

Feature flags with no cleanup become permanent code debt.

I choose the release pattern based on the failure we are trying to limit, then automate enough evidence that promotion becomes a controlled engineering decision rather than hope.