Deployment and Implementation
Deployment is not release
A deployment moves an artifact into an environment; a release exposes it to users. Mature pipelines separate the two with a feature flag, so a bad build can be disabled in seconds without a redeploy. Build once, promote the same immutable artifact through environments, and inject configuration at deploy time rather than rebuilding per stage.
Strategies you must be able to compare
- Rolling: replace instances in batches. Cheap, but both versions serve traffic simultaneously, so the schema and API must be compatible.
- Blue/green: stand up a full parallel stack and switch traffic. Fast rollback, roughly double the transient capacity.
- Canary: send a small slice of traffic to the new version, watch metrics, then widen. Best at catching problems that only appear under real traffic.
Traps candidates fall for
- Naming canary when the question describes an instant full traffic switch (that is blue/green).
- Assuming a green pipeline means a successful release; validate with smoke tests and user-facing signals.
- Changing the database before deploying code that tolerates both schemas. Expand, migrate, then contract.
- Having a rollback plan that was never executed; an untested rollback is a hypothesis.
- Bundling unrelated changes into one release so blame and rollback become impossible.
Rule of thumb
Every deployment must have a tested rollback or a forward-fix path, and every database change must be backward compatible with the previous release for at least one deploy cycle.
Worked example
A checkout service changes its orders table and its API contract. Sequence: add the new nullable column and dual-write (expand), deploy code reading both shapes, backfill, shift traffic 5 percent, then 25 percent, then 100 percent with automated gates on error rate and p95 latency, then remove the old column in a later release. A canary that fails a gate rolls back before any customer notices.