Tame the manual release into a runbook
It is Friday at 16:50 and the only person who knows how to deploy it is out sick.
What you'll build
You will replace the copy-paste deploy folklore with a documented, repeatable release: idempotent build, tag-by-SHA, push, and apply scripts driven by a single "make release" entrypoint, plus a runbook a teammate can follow cold. The git short SHA becomes the one source of truth for "what version is live", so the api and worker can never silently drift to different builds again, and rollback becomes "release the previous SHA".
See how we teach, before you sign up
You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
namespace: beacon
spec:
replicas: 2
selector:
matchLabels: { app: api }
template:
metadata:
labels: { app: api }
spec:
containers:
- name: api
image: registry.example.com/beacon/api:bootstrap
ports:
- containerPort: 8000
envFrom:
- secretRef: { name: beacon-env }
Reading this file
name: apiThe Deployment name your apply/rollout scripts reference. Stable across every rung.image: registry.example.com/beacon/api:bootstrapThe placeholder tag you will overwrite with the git SHA at release time.- name: apiThe container name. kubectl set image addresses it as deployment/api api=...; this name must match.containerPort: 8000The stable contract: the api always listens on :8000.
Provided by the platform team. You do NOT author or redesign this; you only target the container name when setting the image. Note the service name api and the container name api are the stable contract.
That's 1 of 7 explained code blocks in this single project.
The build, milestone by milestone
- 1
Pin the version to the git short SHA
4 guided stepsThe whole drift problem from last week came from the tag 'latest' meaning nothing. If the tag is the commit, then 'what is live?' and 'what is in git?' become the same question, and rollback is just 'release the previous SHA'.
- 2
Build and tag both images by SHA, idempotently
4 guided stepsTagging by SHA is what makes a release auditable and reproducible. Idempotence is what makes the runbook trustworthy: a teammate who is unsure whether a step ran can just run it again.
- 3
Push the tagged images to the existing registry
4 guided stepsThe cluster pulls from the registry, so the release is not real until the images are there. Making push retry-safe means a flaky network does not force a teammate to restart the whole runbook from the top.
- 4
Apply to the cluster and wait for a real rollout
4 guided stepsA deploy that returns success before pods are ready is how the Friday outage hid. Waiting on rollout status turns 'I ran apply' into 'the new version is serving', and a failed rollout becomes a non-zero exit your runbook can react to.
- 5
Wire one entrypoint and write the runbook
4 guided stepsScripts without a single entrypoint and a written runbook are still folklore. The deliverable of this rung is that a teammate who has never deployed it can run one command, read one page, and know both how to ship and how to undo. The non-empty SHA guard is what keeps a dirty tree from poisoning the release with an empty tag.
What's inside when you start
You'll walk away with
This is portfolio-grade. Build it free.
Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.
Start building