Skip to main content
Welcome back. In this lesson we cover deployment types and strategies — essential for both the CNPA exam and real-world platform engineering. Modern production expects frequent, zero-downtime releases, rapid rollbacks, and metrics-driven rollouts. Exam questions and architecture decisions will test your ability to balance speed, safety, and cost.
Understand the trade-offs between risk, cost, and complexity. Certification scenarios commonly ask you to select the best strategy given downtime tolerance, resource budget, and rollback requirements.
The image outlines key aspects of modern deployments, emphasizing zero-downtime, multiple daily deployments, risk mitigation, and data-driven rollouts. Each point highlights the importance of continuous availability, team velocity, minimizing failures, and using metrics for decisions.
You must balance deployment speed with operational safety. Exam scenarios often require mapping routing, checks, and rollback mechanics to a specific business SLA. Core concepts to keep in mind
  • Deployment target: where the new version runs (same instances, new instances, or a separate environment).
  • Traffic routing: how users reach the new version (load balancer, service mesh, DNS).
  • Health checking: how you validate the new version (local probes, integration checks, or percentage-based canaries).
  • Rollback mechanism: how you recover when a rollout fails (automated rollback, manual reversion, or traffic re-routing).
The image displays four core deployment concepts for platform engineers: Deployment Target, Traffic Routing, Health Checking, and Rollback Mechanism, each with a brief description.
Deployment strategies directly affect user experience and operational risk. Poor choices can cause downtime or increase operational overhead. Certification-style questions commonly ask when a health check should pause a rolling update versus trigger an automated rollback.

​
Rolling (in-place) deployments

  • Replace instances incrementally (one-by-one or in small batches).
  • Uses existing capacity; no duplicate environment required.
  • Built-in safety: you can pause and resume the update on health-check failures.
  • Kubernetes Deployments use rolling updates by default.
Key considerations:
  • maxUnavailable and maxSurge — how many pods can be unavailable or created during updates.
  • Readiness and liveness probes, timeouts, and inter-batch delays.
  • SLA-based sizing: if an SLA requires 80% capacity, calculate maxUnavailable accordingly.
The image outlines key benefits of rolling deployments for gradual instance replacement, highlighting concepts like instance-by-instance updates, resource efficiency, built-in safety, and default patterns.

​
Blue-Green deployments

  • Maintain two full environments: Blue (current) and Green (new).
  • Validate Green, then switch traffic to Green; revert to Blue if problems occur.
  • Extremely low runtime risk because cut-over only happens after testing.
  • Requires roughly double capacity while both environments run.
Use cases and cautions:
  • Ideal for major releases, schema changes, and risky integrations.
  • Databases and stateful services complicate blue-green: replicating very large DBs or maintaining multi-version migrations may be impractical.
Blue-green simplifies runtime rollback but can introduce complexity for stateful components and database migrations. Plan migration strategies (backfills, feature toggles, or compatibility layers) before switching environments.
The image outlines the concept of a Blue-Green deployment strategy, detailing the stages of Blue Environment (current production), Green Environment (new version deployment), Instant Switch (traffic routed to new version), and Full Rollback (reverting to old version if issues occur).
The image is about Blue-Green Architecture and Platform Orchestration, highlighting service routing, environment labeling, and state management.
The image outlines platform engineering patterns related to Blue-Green Architecture, including automated orchestration, validation gates, and rollback automation.
For platform teams, offering blue-green as self-service means handling capacity planning, validation gates, and rollback automation so developers can operate safely without manual intervention.
The image outlines the advantages of "Blue-Green" deployment for platform teams, featuring three cartoon characters: Swati, Alan, and Phuong, each highlighting specific benefits.

​
Canary deployments

  • Canary deploys expose a small subset of users to the new version while monitoring metrics (error rate, latency, business KPIs).
  • Start small (e.g., 5%) and increase traffic based on observed health.
  • Modes:
    • Pure canary: a small percent, validate, then cut over or revert.
    • Progressive/linear canary: increase traffic in steps (e.g., 5% → 10% → 25% → 100%) with checks at each step.
Canary blends blue-green safety with rolling efficiency and enables data-driven decisions.
The image describes the core process of Canary Deployments for gradual traffic shifting, illustrating steps like routing a small traffic subset, monitoring metrics, progressively increasing traffic, and performing automatic rollbacks.
Tooling note: the Argo project family — Argo CD, Argo Workflows, and Argo Rollouts — offers advanced canary features. Argo Rollouts supports progressive traffic shifting, metric analysis, pause/resume, and automated rollback, making it a popular platform-level service.
The image outlines advanced canary management features in CNCF Argo Rollouts, including metrics analysis, pause and resume, and progressive traffic shifting.
The image is a diagram highlighting the benefits of CNCF Argo Rollouts for advanced canary management, focusing on declarative rollouts, observability integration, and risk mitigation. The platform team provides this as a standardized canary deployment service.
Canaries are ideal when you want to minimize risk, validate behavior under real traffic, and have observability and automation integrated into CI/CD.

​
Recreate (stop-and-redeploy)

  • Destroy all existing instances, then start new ones with the updated version.
  • Simple to implement; usually incurs brief downtime.
  • Rollback is a straightforward redeploy of the previous release.
Use cases:
  • Maintenance windows, development/test environments, or emergency fixes where short interruption is acceptable.
The image outlines the "Recreate Strategy" for software deployment, detailing steps including stopping all instances, deploying a new version, and experiencing brief downtime. It highlights when downtime is acceptable during the process.

​
A/B testing and feature flags

  • A/B testing is a business experimentation pattern: expose features to segments and measure metrics (conversion, retention).
  • Not strictly a deployment strategy, but often combined with deployments: deploy code dark and toggle features via flags.
  • Feature flags enable targeted rollouts, instant rollback by toggling off, and experimentation without redeploying.
The image outlines four aspects of A/B testing for business feature validation: business experiments, user segmentation, business metrics, and feature flags. Each aspect has a brief description of its purpose.
The image outlines the comparison between A/B testing and deployment strategies, highlighting how A/B testing measures business outcomes, deployment strategies control technical risk, and canary deployments enable safe rollout of A/B test setups. It also mentions that feature flag systems integrate with deployment pipelines.
The image explains feature flags as a way to decouple deployment from release, highlighting four aspects: Deploy Dark, Targeted Rollouts, Instant Rollback, and Continuous Experimentation.

​
Other patterns (brief)

  • Ring deployments: progressive rollout across user cohorts (canary-like but organized as rings).
  • Regional rollouts: deploy by geography to limit blast radius.
  • Shadowing: send production traffic copies to a new version without affecting users (for correctness and performance testing).
  • Chaos/failure testing: intentionally induce faults to validate resilience.

​
Decision factors — which strategy to choose?

  • Rolling: low resource cost, moderate complexity; suitable when capacity is constrained.
  • Blue-Green: low runtime risk, high resource cost; recommended for major releases and migrations.
  • Canary: best for minimizing risk and enabling data-driven rollouts; requires observability and automation.
  • Recreate: simplest, causes downtime; acceptable for non-critical services or scheduled maintenance.
If you need immediate rollback and zero-downtime guarantees, prefer blue-green or canary. Rolling and recreate may require redeploys to recover.
The image is a decision framework chart for choosing the right strategy, comparing four deployment strategies: Rolling, Blue-Green, Canary, and Recreate based on downtime, resource cost, complexity, risk level, and best use cases.

​
Platform engineering perspective

  • Platform teams should expose these strategies as self-service capabilities — opinionated, automated pipelines and orchestration — so developers can deploy safely without manual operations.
  • This is core to DevOps evolution: make complex operations simple services.

​
Summary — key takeaways

  • Know the essentials: Rolling (in-place), Blue-Green, and Canary. Recreate and variations (rings, regional, shadowing) are useful in specific contexts.
  • Choose based on trade-offs: downtime tolerance, resource cost, complexity, and rollback needs.
  • Feature flags and A/B testing decouple release from deployment and enable targeted experiments and instant rollback without redeploying.
  • Platform teams should standardize and automate these strategies so teams can ship fast, safely, and cost-effectively.
The image outlines three essential deployment strategies: Rolling Deployments, Blue-Green, and Canary, each with a brief description.
That covers deployments, feature flags, and the common strategies platform teams use. Thank you for reading — see you in the next lesson.

​
Quick comparison table

Watch Video