Deployment strategy is a per-release decision, and the data layer is where habit gets expensive

A scenario-based guide published by devops.com makes a narrow, useful argument: the deployment approach for a given release should follow from release risk, rollback needs and verification capability, not from precedent ^[1]. It matters because, on the guide's own account, most teams answer the question by reaching for whatever they used last time, which it calls a habit rather than a strategy, and habits formed in one deployment context carry real risk when applied uncritically to another ^[2].

The four options differ less in how code moves than in what can be undone, how fast, and at what cost.

Rolling deployments swap old instances for new ones incrementally, so mid-rollout some instances run each version ^[3]. That is fine for stateless services with guaranteed backward compatibility, and it is the wrong tool for schema changes, stateful applications, or any case where two live versions produce behavioral inconsistencies users can see ^[4].

Blue-green keeps two identical environments, one live and one idle; the new version goes to the idle side, is verified there, and traffic cuts over completely, with the old environment left standing as an immediate rollback target ^[5]. The switch and the rollback are both instant and mixed-version behavior disappears; the bill is two full environments running simultaneously, with infrastructure implications at large scale ^[6].

Canary sends a small percentage of traffic to the new version while the majority stays on the old, raising the percentage as confidence grows ^[7]. It buys the one thing blue-green cannot, which is real production signal at controlled scale before full rollout, and it is significantly more complex to implement and monitor, so the guide reserves it for releases with genuine uncertainty about behavior under real traffic ^[8].

Feature flags decouple deployment from release: code ships disabled and is enabled by configuration rather than by another deployment, which allows gradual exposure, A/B testing and instant rollback without redeploying ^[9]. The cost is recurring rather than one-off, in flag state to manage, old code paths to clean up, and flag logic that turns into technical debt if it is not actively maintained ^[10]. Blue-green and flags both advertise instant reversal, but the unit differs: one reverses an environment, the other a single shipped code path ^[15].

The reflex does the most damage at the data layer. If the previous release was a routine, backward-compatible service update with strong staging results, rolling was the correct call, and the guide's first worked scenario says exactly that, citing the balance of simplicity and risk management ^[12]. Carry that choice into a release containing a schema change and it lands on the case the guide rules out ^[4][16]. Its remedy for schema work is an expand-contract pattern combined with a deliberately chosen deployment strategy, not a strategy inherited from the last change ^[11]. The stated test for everything else is the balance of speed, reversibility and production confidence for the specific release ^[13]. The failure mode is framed less politely: get it right and releases are predictable, reversible and low-drama, get it wrong and a straightforward deployment becomes a Friday afternoon incident investigation ^[14].

The diagnostic is cheap. If nobody on the team can say why this release is rolling rather than blue-green, the guide's description of habit applies ^[2], and the three costs to check for are the second environment on the infrastructure bill ^[6], the monitoring build-out canary requires ^[8], and the flag count nobody has removed ^[10].