🎉 DevOps Interview Prep Bundle is live — 1000+ Q&A across 20 topicsGet it →
All Articles

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.

DevOpsBoysJun 9, 20264 min read
Share:Tweet

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:

yaml
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: stable

2. 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:

yaml
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 switch

Difference 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.

python
# 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.

yaml
# 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

ToolWhat it does
Argo RolloutsCanary + blue-green for Kubernetes, Prometheus-based analysis
FlaggerWorks with any service mesh (Istio, Linkerd, NGINX), metric-based rollouts
Istio / LinkerdService mesh traffic splitting (used by Flagger)
LaunchDarklyFeature flags as a service
FlagsmithOpen 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

Browse fixes
Newsletter

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

Comments