[DevOps Architecture] Deploy Strategy

About this article

As the eighth installment of the “DevOps Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains deploy strategy.

The mainstream culture today is deploying frequently, small, safely. Deploy frequency, failure rate, and recovery speed are the core of DORA4 metrics. This article covers strategies like Rolling / Blue-Green / Canary / Feature Flag / Shadow Deployment / Dark Launch, rollback design, and AI-era auto Canary judgment.

What is deploy strategy

Deploy strategy is “the playbook for how you deliver a new version of software to the production environment.”

Think of road construction. You could shut down every lane at once and do the work (all-at-once deploy), or you could close one lane at a time and keep the rest open (rolling update). For extra caution, you could repave a side road first to check for problems before moving to the main road (canary release). Software is the same — deciding “to what scope, in what order, and with how much safety margin” you roll out a new version ahead of time is deploy strategy.

Why deploy strategy is needed

First, because a failed deployment is the single largest source of incidents. A large share of production outages happen at the moment of release, and how you deploy is therefore a reliability decision. Second, because deploying frequently raises quality. Small, frequent changes shrink the blast radius of each one and shorten the time to identify a cause. Third, because it underwrites the speed of the business. Being able to ship a feature the day it is ready, rather than waiting for a monthly window, is a competitive property.

The main strategies

There are multiple patterns in deploy strategies. Each differs in risk, cost, and complexity, so use according to system.

Among them, Canary matters because it can catch problems visible only in production early. Expose the new version a little to real user behavior, real data distribution, and real traffic patterns unreproducible in test env, and on anomaly, retreat with minimum affected users. Cases of breaking only in production despite no problems in staging aren’t rare, and Canary is the last safety net.

But Canary has corresponding implementation costs. Traffic routing splitting requests by ratio (Service Mesh or Ingress weighting), and metric auto-judgment comparing new and old error rates and latencies (Flagger, Argo Rollouts, etc.) are needed - starting from Canary at the stage without monitoring foundation is hard. That’s why “Canary + Feature Flag” is told as the modern standard, adopted as the equipment set for fine control and minimizing problem impact.

Rolling update and blue-green

The method of sequentially replacing old version with new. Kubernetes’s default strategy, replacing some pods to new version. Simple with no additional infrastructure, but the downside of slow rollback on problems.

Suited for minor updates but unsuited for schema changes or incompatible changes.

Blue-green is the other half of that pair.

The method of preparing 2 production environments (Blue, Green) and switching with load balancer. Blue is current, Green is new - if no problems, switch traffic to Green; on problems, just return to Blue.

Canary — catching early what only production shows

The method of phased deployment of new version to some users (5% → 20% → 50% → 100%). Problems can be detected early, minimizing affected users. As the safest deploy strategy, standardized in SRE organizations.

Auto-monitor error rate and latency at each phase, ideally auto-rolling back on anomaly. Tools like Argo Rollouts, Flagger, Spinnaker support this.

Feature flags — separating deployment from release

The method of deploying code to production while dynamically controlling feature ON/OFF. Separates deploy and release, creating the state of “deployed but invisible to anyone.” Usable for A/B tests, phased releases, emergency stops too.

Separating “code deploy” and “feature release” is the modern thinking, dramatically lowering risk.

Database migration and automatic rollback

Deploys with DB schema changes are the most difficult area. Special design is needed to maintain code-DB integrity while changing without downtime. Expand and Contract pattern is standard.

Trying to do everything in one release stops production. Phased migration over multiple releases is the modern best practice.

Automatic rollback is the other half.

Mechanism to auto-revert to previous version on detecting anomaly after deploy. No waiting for human judgment, minimizing damage. Auto-judges by monitoring metrics (error rate, latency, SLO).

Not depending on human operators is modern - creating a 24-hour auto-protected state.

Three scenarios

If you are building solo or on a small web service

GitHub Actions with a rolling update is enough. A feature flag built yourself from a config file or a database column is fine, and no extra infrastructure is needed. Start from deploying automatically to production on a green CI run and reverting to the previous commit by hand if something goes wrong.

Personal / Startup: Ship in One Month Is Correcten.senkohome.com/arch-intro-case-startup/

If you are a small or mid-size SaaS

This is the stage for GitHub Actions with a canary (Argo Rollouts) and feature flags (Unleash, PostHog). Roll out in three steps of 5, 20 and 100 percent, monitoring error rate and P95 latency automatically and rolling back automatically on an anomaly. Databases migrate without downtime through expand and contract. As microservices multiply, moving to ArgoCD with GitOps and Flagger for independent per-service deployment makes hundreds of deployments a month realistic.

Small-Mid SaaS - Lean on Managed and Run with Few Peopleen.senkohome.com/arch-intro-case-saas/

If you are a large enterprise or in finance

Blue-green with a pre-approval workflow and a change advisory board. Fix release times outside business hours, apply database schema changes in a separate release beforehand, and retain audit logs permanently. Where the cost of an incident is extremely high, being certain you can retreat matters more than speed.

Large-Enterprise Core: Design That Holds Up for Yearsen.senkohome.com/arch-intro-case-enterprise/

DORA 4-metric numerical gates

Note: Industry baseline values as of April 2026. Will become outdated as technology and the talent market shift, so requires periodic updates.

The world standard for measuring deploy-strategy quality is the DORA 4 metrics.

Canary deployment numerical gates: Phase 1: 1-5% / 15 min observation, Phase 2: 20% / 30 min, Phase 3: 50% / 1 hour, Phase 4: 100%. Auto-rollback on error rate exceeding old version + 0.5% or P99 > old version x 1.2. This is the Argo Rollouts / Flagger standard judgment criterion.

To aim for Elite level, multiple daily deploys + within-1-hour recovery. Canary + Feature Flag is the premise.

AI decision axes — AI assists the deployment decision

AI assists deploy judgment

The judgment logic for SLI (error rate, latency) during Canary deployment is an area AI can analyze and propose. Rules like “auto-rollback if P99 latency exceeds 300ms on 5% Canary traffic” are defined in code, and AI validates threshold reasonableness from past deploy history.

Additionally, automated analysis flows where AI detects anomalies from post-deploy logs and metrics, estimates “what’s causing the diff from last deploy,” and notifies via Slack are becoming widespread.

Feature Flag and AI-generated code compatibility

When delegating code generation to AI, having Feature Flags as a premise enables safe releases. Place AI-written code under a Feature Flag, first expose to internal users only → gradually roll out if no issues - this flow minimizes quality risk from AI-generated code.

Pitfalls and forbidden moves

Here are the six most dangerous ways a deployment goes wrong. Every one of them carries enough force to tip a company over.

Setting the deployment time during peak business hours, and never rehearsing a rollback, are the operational slack that breeds incidents too. Once a quarter is the guideline for a rehearsal.

Author’s note - “just one deploy” that erased a company

Cases of breaking down by underestimating deploy strategy are repeatedly carved into industry history.

The August 2012 Knight Capital incident is the extreme north of these lessons. Knight Capital, a major US market maker, on releasing new auto-trading features, put production live with old code remaining on 1 of 8 trading servers. The old code mistook a new flag for a different feature, triggering massive unintended auto-trades, losing about $440M in just 45 minutes (exceeding then-equity), with the company effectively bankrupt. A symbolic case where one human error of “missing just 1 server in deploy steps” erased a public company.

Another famous one is the June 2021 Fastly global outage. At major CDN vendor Fastly, one customer config change tripped a latent bug, simultaneously dropping major worldwide sites - Reddit, Amazon, UK government sites, NYT, CNN - for about 1 hour. A case told to show modern deploy-risk depth where “even protecting your own production, one upstream config change stops the world.”

Both have “deploy-strategy laxness” as the lethal blow, slapping home that without Canary, Feature Flag, and auto-rollback equipment, human errors directly link to corporate life-or-death.

Recording decision rationale

Deploy-strategy selection directly impacts incident risk and release speed, so recording why you chose that strategy as an ADR is important.

Store ADRs in docs/adr/ as Markdown, with a rule to always file a new ADR when changing deploy strategy - this keeps decision history traceable. The greatest value of ADRs is that when you look back later, “why we made this choice” is immediately clear.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• Deploy strategy (Rolling / Blue-Green / Canary)
• CI/CD tool (GitHub Actions etc.)
• Feature Flag adoption (LaunchDarkly etc. or custom)
• Phased-release ratio (5→20→50→100)
• Auto-rollback criteria (SLI threshold)
• DB-migration strategy (Expand / Contract)
• Deploy-frequency target (daily / weekly / monthly)

Related Articles

Summary

This article covered deploy strategy, including Rolling, Blue-Green, Canary, Feature Flag, Progressive Delivery, auto-rollback, and zero-downtime DB migration.

Deploy small and frequently, make Canary+Feature Flag standard, auto-rollback by SLI, non-stop DB changes via Expand and Contract. That is the practical answer for deploy strategy in 2026.

Next time we’ll cover monitoring and observability (metrics, traces, log integration).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.