Deployment strategies
Choose how new versions reach users - recreate, rolling, blue-green, canary - and how to get back fast when one misbehaves.
- Compare recreate, rolling, blue-green and canary deployments
- Plan a rollout with batches and bake time, and decide between rolling back and rolling forward
- Run a blue-green switch with smoke tests as the gate
Release Night’s strategy was “stop everything, copy files, start everything, pray”. That’s the recreate strategy, and it comes with downtime. Here are the alternatives:
| Strategy | How it works | Downtime | Rollback | Extra capacity |
|---|---|---|---|---|
| Recreate | stop all old, start all new | yes | redeploy the old version | none |
| Rolling | replace servers in batches | no | roll back batch by batch | a little |
| Blue-green | run the new version on an idle copy of production, then switch all traffic | no | switch back instantly | double, during the switch |
| Canary | send a small share of traffic to the new version, compare metrics, then widen | no | send the share back to 0 | a little |
Between batches or canary steps, bake for a while: watch error rates and latency before going on. Pair any strategy with feature flags to separate deploying from releasing.
1import math
2
3servers, batch_percent, minutes_per_batch = 10, 30, 12
4batch = math.ceil(servers * batch_percent / 100)
5for start in range(0, servers, batch):
6 end = min(start + batch, servers)
7 print(f"servers {start + 1}-{end} at t={start // batch * minutes_per_batch} min")servers 1-3 at t=0 min servers 4-6 at t=12 min servers 7-9 at t=24 min servers 10-10 at t=36 min
Roll back or roll forward?
When a deploy goes wrong, roll back to the last good version first and investigate later - restoring service is the priority, and a tested previous version is the quickest safe state. Rolling forward (shipping a quick fix) can be fine for a tiny, obvious bug when your pipeline is fast - but a rushed fix under pressure is how one incident becomes two.
Rollback only works if it’s practiced and possible: keep the previous artifact, keep database changes backward compatible (expand and contract), and make rollback one command or one click.
Try it
Pick the strategy
Which strategy fits each Byte Bakery situation best?
“An internal admin tool used during office hours; a minute of downtime at night is fine”
“A routine update to 40 identical web servers, with no spare capacity budget”
“A major checkout rewrite where you need to switch back in seconds if anything looks wrong”
“A new recommendation algorithm whose effect on real customers is uncertain”
Key takeaways
Recreate has downtime; rolling, blue-green and canary don’t.
Bake between steps and watch the metrics before going further.
Blue-green gives instant rollback; canaries limit how many users see a bad version.
Roll back first to restore service; make rollback practiced, possible and one step.
Lesson quiz
7 questions · pass with 5 correct · up to 50 XP
Passing this quiz completes the lesson and keeps your streak going. Questions you miss come back in review sessions later.
Practice: automate DevOps chores in Python
Write the small Python tools DevOps teams really build - pipeline runners, plan checkers, metric calculators, scanners - and run them against sample inputs. They run locally in your browser; no servers or cloud accounts needed.
Schedule a rolling deployment
The first input line is servers batch_percent deploy_minutes bake_minutes; the second is the batch that fails during its bake, or none. Each batch has ceil(servers × batch_percent / 100) servers (the last may be smaller) and takes deploy + bake minutes.
Print batch 1: servers 1-3, t=0-15 ok for each batch. If a batch fails, print it with FAILED instead of ok, then rollback: 6 servers back on the old version at t=35 (the batch’s end plus one deploy time) and stop. Otherwise finish with done at t=60: 12 of 12 servers on the new version.
- Smooth rollout
- Failure in batch 2
- Uneven last batch
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Run a blue-green switch
The first input line is the live environment and its version, like blue v1.0; the other environment starts empty and unverified. Each following line is a command:
deploy VERSION- deploys to the idle environment, which becomes unverified:green: deployed v1.1.smoke pass|fail- records smoke tests on the idle environment:green: smoke tests passedorfailed.switch- if the idle environment has a verified version, it becomes live and the old live one stays as a verified standby:switched: green v1.1 is live, blue v1.0 on standby. Otherwiseswitch refused (green is not verified).
Finish with live: green v1.1.
- Release and rollback
Python runs in a sandboxed browser worker with a 60 second time limit. Its runtime loads from the Pyodide CDN; your code stays in this browser.
Questions about this lesson
Stuck? Ask. Figured something out? Share it. Explaining is one of the best ways to learn.
Loading posts…