intellimetrics Learning
Modern DevSecOps Foundations Module 4 · Test and Release

Decouple Deploy from Release

Last reviewed · content updated

Intermediate

What you'll learn

~20 min
  • Separate deploying code from releasing features - the idea beneath every modern release strategy
  • Roll out progressively with health gates, sized to your platform
  • Decide rollback vs roll-forward in advance with a rehearsed rule

One idea, load-bearing

Every modern release technique — canary, dark launch, guarded rollout, A/B — rests on a single separation: deploying code (bits reach production) and releasing features (users experience the change) are different events, decoupled in time. Code ships dark behind a flag; release is flipping the flag — per cohort, per percentage, per moment of your choosing; un-release is flipping it back, in seconds, with no deploy. Lesson 1.1’s stability finding is the motivation: AI-era teams ship more and break more unless something absorbs the speed — and this decoupling is the absorber: deploys become frequent and boring, releases become controlled and reversible.

Flags, behind an abstraction

The mechanics are feature flags, and the 2026 design guidance is about how you consume them, because the vendor landscape is consolidating under everyone’s feet (two major experimentation vendors were acquired in 2025 - Eppo by Datadog, Statsig by OpenAI - and this category has kept changing hands since, so confirm who owns yours before you depend on it):

- Code against an ABSTRACTION, not a vendor SDK: the OpenFeature API is the
  emerging standard interface (a CNCF incubating project as of this
  review - "emerging" is the honest word), with providers behind it. For Azure shops the boring-correct
  backing store is App Configuration's feature management (whose flag
  types - simple switches, percentage rollouts, and variant/experiment
  flags - map exactly to how flags get used).
- Flags have TYPES and lifecycles: release flags are TEMPORARY (they die
  when rollout completes - a flag registry with expiry, exactly like every
  exception in this training); ops kill-switches are permanent and
  documented; experiment flags belong to the experiment's lifetime.
- The flag registry gets an owner and a cleanup cadence - flag debt is
  real debt, and a codebase of orphaned conditionals is the failure mode
  that gives flags a bad name.

Progressive rollout, sized to your platform

With deploy decoupled, rollout becomes a traffic question, and the right machinery depends on where you run — the ladder, boring-first:

App Service        deployment SLOTS: stage the new version, swap, swap back.
                   Blue-green in two clicks; still the right answer for
                   plain web apps.
Container Apps     REVISIONS + traffic weights: 10% to the new revision,
                   watch, promote. First-party canary for containers.
Kubernetes         a progressive-delivery controller (Argo Rollouts is the
                   de facto standard) automating stepped traffic + analysis.
Any of the above   + FLAGS for the user-facing features riding the deploy -
                   the platform moves traffic; flags move features.

Two honesty notes from the research: fully automated metric-driven canary analysis remains a minority practice — most real teams do stepped traffic with human-watched health gates, and that’s a fine intermediate rung (no adoption percentages exist worth quoting; claims otherwise are vendor content). And the health gate itself is just Lesson 2.2’s always-appended health report growing teeth: define the metrics (error rate, latency p95, the business counter that matters) before the rollout, with thresholds that halt promotion automatically.

The decision you make in advance

When the gate trips at 10%, someone must choose: roll back or roll forward? Under incident adrenaline is the worst time to reason about it, so the consensus practice is a pre-agreed rule, rehearsed:

Can you be back on the old version in <5 minutes without data risk?
  YES -> ROLL BACK. Always. Diagnosis happens after recovery, on a
         system that works. (Revision/slot/flag reversal makes this true
         for most changes - that's WHY this module built them.)
  NO (schema moved, data written, migration ran) ->
      cause known + fix trivial? -> roll forward deliberately
      otherwise -> this is why Lesson 4.4 exists: the migration
      discipline is what keeps this branch RARE

The load-bearing observation: rollback is cheap exactly when the database discipline made it cheap — backward-compatible schema changes (next lesson) are what let the five-minute rule answer YES. Release strategy and migration strategy are one system wearing two lessons.

The artifact - per-tier release strategy for Meridian:
1. Map each app tier from the routing contract (1.3) to its rollout
   machinery: dispatch app (critical) -> revisions + 5/25/100% steps +
   automated gate on error rate; internal tools -> slot swap + smoke;
   batch jobs -> flag-gated activation
2. Flag plumbing: OpenFeature-style abstraction over App Config, the flag
   registry with type/owner/expiry, and the cleanup cadence wired to 1.2's
   branch-policy work items
3. The rollback rule card: the 5-minute question, the per-tier answer,
   WHO decides (the on-call, alone, no meeting), and the quarterly drill -
   an unrehearsed rollback is a hypothesis, not a capability
4. Health gates: per-tier metrics + thresholds, defined here, consumed by
   the deploy templates from Module 2
KNOWLEDGE CHECK

Meridian ships a new outage-map feature: deployed dark Monday, flag to 10% of users Wednesday morning. At 11 a.m. the health gate flags elevated API latency in the cohort. The engineer proposes: 'It's only 10%, latency isn't errors, and a rollback deploy means re-running the whole pipeline — let's watch it through lunch and decide after.' What does this lesson's machinery say?

Key takeaway

Deploy dark, release by flag, and un-release in seconds — code behind an abstraction with typed, expiring, owned flags; traffic moved progressively by the platform’s native machinery with pre-defined health gates; and the rollback decision made in advance by the five-minute rule, rehearsed quarterly. Cheap reversal is what makes strict gates painless — and the database discipline that keeps reversal cheap is next.

Search lessons