Topic 3.4 — Deployments · cram sheet

Strategies

Only runOnce, rolling, canary are strategy: keywords. Blue-green and ring are patterns you build. Fastest rollback for flagged code = turn the flag off.

Ordered dependencies

• Stages are sequential by default; dependsOn: [A, B] waits for all.
• A completed stage is not a healthy dependency. Gate with postRouteTraffic health checks or a Query Azure Monitor alerts / Invoke REST API check.

Minimising downtime

• Slot swap: staging is already warm → no cold start. Swap back to roll back.
• Slot settings are sticky — a connection string that isn't one follows the app and production writes to the staging database.
• rolling with maxParallel: 2 of 6 VMs → four stay in service.

Hotfix path

• Branch from the released tag, never main.
• Merge back — the most-tested failure is the bug reappearing at the next release.
• Reduce scope, not rigour. Break-glass is agreed in advance with the resource owner.

Resiliency

• postRouteTraffic detects under real traffic; on: failure reverses.
• Exclusive lock stops a second deploy during an incident.
• Deployment scripts must be idempotent — retries mean a step may run twice.

Feature flags (App Configuration)

• Flag = binary on/off + code block. Feature manager = lifecycle + caching. Filter = per-request rule.
• Uses: dark deployment · test in production · flighting · instant kill switch · selective activation.
• Flag state is cached — the kill switch is not literally instant.

Containers, binaries, scripts

• Build once, deploy many. Environment differences are configuration.
• Promote by digest — :latest is a mutable pointer, so tested ≠ deployed.
• Scripts are the least immutable → idempotent, pinned tool versions.

Database deployments

• Schema must support old and new app versions during rollout.
• Expand → Migrate → Contract. The drop is the only irreversible step, so it goes last.
• on: failure restores code, not data.