OpsCanary
Back to daily brief
cicdreleasePractitioner

Mastering Blue Green Deployments: Strategies for Seamless Releases

5 min read Argo Rollouts DocsApr 23, 2026
PractitionerHands-on experience recommended

Blue Green Deployment exists to solve the challenges of application updates, particularly the risks of downtime and service disruption. By maintaining two identical environments—blue (current version) and green (new version)—you can switch traffic seamlessly. This strategy allows for quick rollbacks if issues arise, ensuring a reliable user experience.

The rollout controller plays a crucial role in managing traffic routing. It modifies a Service resource to direct traffic between the old and new ReplicaSets based on the unique hash injected into the service's selectors. Key parameters include autoPromotionEnabled, which controls whether the new ReplicaSet is automatically promoted to active status once it’s healthy, and scaleDownDelaySeconds, which configures the wait time before scaling down the old ReplicaSet after the switch. You can also utilize a previewService to test the new version before full promotion, allowing for real-world validation without impacting production traffic.

In production, be aware of the propagation delay when changing selectors on a service. This delay can lead to temporary inconsistencies as nodes update their IP tables. Properly configuring your rollout strategy, including maxUnavailable and previewReplicaCount, is essential to maintain service availability during updates. Always test your configurations in a staging environment to avoid surprises during production rollouts.

Key takeaways

  • Utilize autoPromotionEnabled to control the timing of new ReplicaSet promotions.
  • Configure scaleDownDelaySeconds to prevent abrupt traffic shifts and allow for rollback.
  • Implement a previewService for testing the new version without affecting live traffic.
  • Monitor the propagation delay when changing service selectors to avoid traffic inconsistencies.
  • Set maxUnavailable to manage the number of pods that can be down during updates.

Why it matters

In production, Blue Green Deployments can significantly reduce downtime and improve user experience during application updates. By allowing for quick rollbacks, you mitigate the risk of deploying faulty code.

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

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →

Get the daily digest

One email. 5 articles. Every morning.

No spam. Unsubscribe anytime.