What is Progressive Delivery? Explained Simply
Progressive delivery is how modern teams deploy safely — canary releases, feature flags, and blue-green deployments. Here's what it means and how it works in Kubernetes.
Progressive delivery is the practice of releasing software gradually — to a small subset of users first, measuring what happens, then rolling out to everyone. If something breaks, only a small percentage of users see it.
It's the opposite of the old way: "deploy to everyone and hope for the best."
Why Progressive Delivery
Traditional deployment: push code → all users get the new version at once.
Problem: if the new version has a bug, 100% of your users hit it.
Progressive delivery: push code → 5% of users get it → check error rates → if OK, roll out to 25%, then 100%.
Result: bugs affect 5% of users, not 100%. You catch them before full rollout.
Three Patterns
1. Canary Release
Send a small percentage of traffic to the new version. Gradually increase the percentage if metrics look good.
Before: [v1] ←── 100% traffic
During: [v1] ←── 95% traffic
[v2] ←── 5% traffic
After: [v2] ←── 100% traffic (v1 removed)
In Kubernetes with Argo Rollouts:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: my-app
spec:
replicas: 10
strategy:
canary:
steps:
- setWeight: 10 # Send 10% to new version
- pause: {duration: 5m}
- setWeight: 30 # If OK, bump to 30%
- pause: {duration: 5m}
- setWeight: 100 # Full rollout
canaryMetadata:
labels:
version: canary
stableMetadata:
labels:
version: stable2. Blue-Green Deployment
Run two identical environments (blue = current, green = new). Switch traffic all at once. Rollback = switch back.
Blue (v1): running, idle
Green (v2): running, receives all traffic
Rollback: switch load balancer back to Blue
With Argo Rollouts:
strategy:
blueGreen:
activeService: my-app-active # Points to current version
previewService: my-app-preview # Points to new version (test before switch)
autoPromotionEnabled: false # Manual promotion (you decide when to switch)
scaleDownDelaySeconds: 30 # Keep old version for 30s after switchDifference from canary: No gradual traffic shift. It's 0% → 100% switch (but you can test the new version privately first via the preview service).
3. Feature Flags
Different from deployment strategies — feature flags control which users see which features at the application code level, not the infrastructure level.
# In your code:
if feature_flag("new-checkout-flow", user_id=user.id):
return new_checkout()
else:
return old_checkout()Popular feature flag services: LaunchDarkly, OpenFeature (open standard), Flagsmith (open source self-hostable).
Feature flags let you deploy code to 100% of servers but enable the feature for only 5% of users. Useful for A/B testing, gradual rollout to specific user segments.
Automated Rollback with Metrics
The real power of progressive delivery: automated rollback based on metrics.
# Argo Rollouts with Prometheus analysis
analysis:
templates:
- templateName: success-rate
startingStep: 2
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: success-rate
spec:
metrics:
- name: success-rate
interval: 1m
successCondition: result[0] >= 0.95 # 95% success rate required
failureLimit: 3
provider:
prometheus:
address: http://prometheus:9090
query: |
sum(rate(http_requests_total{status!~"5.*"}[2m]))
/
sum(rate(http_requests_total[2m]))If the success rate drops below 95% during a canary release, Argo Rollouts automatically rolls back to the previous version. No human needed.
Tools for Progressive Delivery in Kubernetes
| Tool | What it does |
|---|---|
| Argo Rollouts | Canary + blue-green for Kubernetes, Prometheus-based analysis |
| Flagger | Works with any service mesh (Istio, Linkerd, NGINX), metric-based rollouts |
| Istio / Linkerd | Service mesh traffic splitting (used by Flagger) |
| LaunchDarkly | Feature flags as a service |
| Flagsmith | Open source feature flags, self-hostable |
Progressive Delivery vs CI/CD
CI/CD gets code from developer to production. Progressive delivery is about how that code reaches users once it's in production.
They work together:
CI/CD pipeline → builds and deploys to cluster
↓
Progressive delivery → controls traffic to new version
→ monitors metrics
→ auto-promotes or rolls back
When to Use It
Not every team needs this complexity. If you deploy once a week and have 1,000 users, a good test suite + rollback plan is enough.
Progressive delivery pays off when:
- You deploy multiple times per day
- Your service has millions of users (5% of 10M = 500,000 users still affected)
- You want to catch performance regressions automatically
- Your team is tired of manual rollbacks at 2 AM
Learn progressive delivery with hands-on labs at KodeKloud.
Today I Fixed
Short real fixes from production — posted daily
Stay ahead of the curve
Get the latest DevOps, Kubernetes, AWS, and AI/ML guides delivered straight to your inbox. No spam — just practical engineering content.
Related Articles
What is GitOps? Explained Simply for Beginners (2026)
GitOps explained in plain English — what it is, how it's different from traditional CI/CD, and how tools like ArgoCD and Flux work. No jargon.
Argo Rollouts vs Flagger — Which Canary Deployment Tool Should You Use? (2026)
Both Argo Rollouts and Flagger do progressive delivery on Kubernetes. Here's a detailed comparison of features, architecture, and when to pick each.
ArgoCD vs Flux v2 — Deep Dive Comparison 2026
Both ArgoCD and Flux implement GitOps for Kubernetes, but they take very different approaches. Here's a detailed comparison to help you pick the right one.