cicdreleasePractitioner

Mastering Blue Green Deployments: Strategies for Zero-Downtime Releases

5 min read Argo Rollouts DocsMay 31, 2026Reviewed for accuracy

Practitioner — Hands-on experience recommended

Blue Green Deployment exists to solve the problem of downtime during application updates. It allows you to run two environments, 'blue' for the current version and 'green' for the new version. This strategy ensures that if something goes wrong with the new version, you can quickly revert to the old one without impacting users. It’s particularly useful in production environments where uptime is critical.

The rollout controller plays a crucial role by creating a new ReplicaSet whenever there’s a change in the .spec.template field. The active service continues to send traffic to the old ReplicaSet while a preview service directs traffic to the new ReplicaSet. Once the new version is healthy, the active service is updated to point to it. Key parameters include scaleDownDelaySeconds, which configures how long to wait before scaling down the old ReplicaSet, and autoPromotionEnabled, which determines if the new ReplicaSet should be automatically promoted once it’s healthy. You can also set up prePromotionAnalysis and postPromotionAnalysis to evaluate the new version before and after the traffic switch.

In practice, you need to be aware of potential gotchas. For instance, when changing the selector on a service, there’s a propagation delay that can lead to traffic still hitting the old pods. This is where scaleDownDelaySeconds becomes vital, giving nodes enough time to update their IP tables. Additionally, if you're using AWS ALB Ingress, be cautious as it does not support blue-green deployments without risking downtime due to how it updates target groups. Always test thoroughly in your staging environment before rolling out to production.

Key takeaways

→Configure `scaleDownDelaySeconds` to prevent traffic from hitting old pods during updates.
→Use `autoPromotionEnabled` to control when the new ReplicaSet is promoted to active service.
→Implement `prePromotionAnalysis` and `postPromotionAnalysis` for better deployment validation.
→Leverage the `previewService` to test the new version without affecting production traffic.
→Be aware of propagation delays when changing service selectors.

Why it matters

In production, minimizing downtime is critical for user satisfaction and business continuity. Blue Green Deployment allows for safe, controlled releases that can significantly reduce the risk of outages.

Code examples

YAML

1apiVersion:argoproj.io/v1alpha1
2kind:Rollout
3metadata:
4  name: rollout-bluegreen
5spec:
6  replicas: 2
7  revisionHistoryLimit: 2
8  selector:
9    matchLabels:
10      app: rollout-bluegreen
11  template:
12    metadata:
13      labels:
14        app: rollout-bluegreen
15    spec:
16      containers:
17      - name: rollouts-demo
18        image: argoproj/rollouts-demo:blue
19        imagePullPolicy: Always
20        ports:
21        - containerPort: 8080
22  strategy:
23    blueGreen:
24      activeService: rollout-bluegreen-active
25      previewService: rollout-bluegreen-preview
26      autoPromotionEnabled: false