Week 22 Checkpoint: Staging Pipeline
- Recall the Week-22 production stack from memory: Docker, Compose, cloud, deploy, CI/CD, IaC
- Assemble the full chain so push-to-main runs tests + evals + build + deploy to staging
- Start the runbook and rehearse a rollback once, end to end
- Re-quiz the week's weak spots and refresh the spaced-repetition deck
| Spaced-rep warm-up: full Week-22 due deck | 10 min |
| Guided: blank-page recall of the pipeline + gates | 15 min |
| Guided: run the whole line, then rehearse rollback | 25 min |
| Practice: cumulative re-quiz + deck refresh | 15 min |
| Project: staging pipeline report + start the runbook | 40 min |
| Quiz + finalize the punch-list for Week 23 | 15 min |
Builds on: Day 148 — Docker fundamentals · Day 149 — Compose, registries & image hygiene · Day 151 — Deploy lab — container to cloud URL · Day 152 — CI/CD with GitHub Actions · Day 153 — Infrastructure as code & environments
An assembly line isn't proven by admiring the individual stations — the welding robot, the paint booth, the inspector. It's proven by putting a raw chassis in one end and watching a finished, inspected car roll out the other, untouched by human hands. Each station you built this week is impressive alone; the checkpoint is watching them run as one line.
This is a review day, and the drill is a full production run. You push a commit to main and watch, without lifting a finger: the tests run, the AI eval gate runs, the container builds and gets tagged with the commit, it deploys to a staging URL, and a smoke test confirms it answers. Then you practice the thing every real assembly line must be able to do — stop and reverse: roll the deployment back to the previous version and confirm staging reverts. Spaced repetition fits because a pipeline is procedural knowledge — the order of the stations, which gate blocks what, how rollback works — and the only way to know you own it is to run the whole line yourself and fix whatever jams.
Week 22 is where the capstone stops being "code that runs on my laptop" and becomes "a system that ships itself safely." That transition is the single most cited gap between bootcamp projects and hireable engineers: not "can you build a RAG app" but "can you deliver it, repeatedly, with gates and rollback." The staging pipeline you assemble today is the dress rehearsal for the Day-161 production cutover and the exact artifact an FDE demonstrates to a customer's engineering leadership to earn a production slot (Day 169). The review exists because six days of stations built separately always have seams — the gate that isn't a required check, the deploy that has no rollback, the staging that drifted from prod — and finding them on a rehearsal run is free; finding them on a real launch is not.
Guided practice
Blank-page recall: draw the pipeline and name every gate
15 min- Close your notes and editor. From memory, draw the Week-22 assembly line: commit → test → eval-gate → build+tag(SHA) → push → deploy(staging) → smoke test, with rollback looping back to a previous SHA.
- On each arrow/station, annotate the key decision: which check is a *required* status check; where secrets come from; what the image is tagged with; what makes staging meaningful; how rollback selects its target.
- Open your capstone and diff your drawing against reality. Every station you couldn't draw, or that isn't actually wired (a gate that isn't required, a deploy with no rollback), is a punch-list item.
- Record gaps in
STAGING_PUNCHLIST.md.
Run the whole line, then reverse it
25 minDo a full production rehearsal on staging:
- Make a small, safe change (e.g. tweak a copy string), commit to a branch, open a PR. Confirm tests + eval gate run and the PR cannot merge if the gate fails (sabotage a prompt on the branch to prove it, then restore).
- Merge to main. Watch the full line run in the Actions tab: test → eval-gate → build-push → deploy. Confirm the image is tagged with this commit's SHA in the registry.
- Hit the staging URL and run your Day-151 smoke test against it. terminal:
python deploy/smoke_test.py https://STAGING_URL— all green. - Rehearse rollback: identify the previous good SHA, redeploy it (re-run the deploy job pinned to that SHA, or your platform's rollback), and confirm staging reverts. Time it.
- Write the deploy and rollback steps, the staging URL, health checks, and the rollback timing into
RUNBOOK.md.
On your own
Cumulative re-quiz + deck refresh
15 minTake the cumulative Week-22 quiz below (it spans Docker through IaC). For every miss, open the day named in the revisit pointer, re-read only the relevant section, and rewrite that day's weakest flashcard in your own words. Then clear your due spaced-repetition cards for the week, marking honestly — a card you hesitated on isn't learned. Produce a ranked shore-up list before Week 23 (serving, reliability, AI system design), where this pipeline becomes the production cutover.
Hints: if you miss the required-check question, revisit Day 152's branch protection; if you miss the drift or config/secret question, revisit Day 153; if you miss the image-tag question, it ties Days 149 and 152 together.
Week-22 checkpoint: the staging pipeline runs
Prove the assembly line runs end to end. Deliver staging_pipeline_report.md demonstrating, with real artifacts: (1) a push to main triggering the full pipeline — test → eval-gate → build+SHA-tag → push → deploy to staging (link/screenshot the Actions run); (2) the eval gate as a required check blocking a sabotaged-prompt PR and passing when restored; (3) the deployed staging URL answering a real docs-QA query with a passing smoke test run from your laptop; (4) a rehearsed rollback to a previous SHA with the staging service reverting (show before/after and the time it took); (5) RUNBOOK.md started, covering deploy, health checks, and rollback. End with a readiness statement: is the pipeline production-cutover-ready for Week 23, and what one gap (if any) you carry forward with a mitigation.
Common mistakes & misconceptions
- Reviewing by re-reading instead of running the line. The checkpoint tests whether you can operate and reverse the pipeline; rehearse by doing a real push and a real rollback.
- Calling the pipeline done without a required eval-gate check. If a red gate can still be merged, the tripwire is decorative — verify branch protection actually blocks the merge.
- Never rehearsing rollback. An untested rollback is a hope; run it once on staging so it's muscle memory before a real incident (Day 158).
- Letting staging drift from prod. If staging is a different shape or skips a component, a green staging run stops predicting production — keep them the same shape.
- Deploying a moving :latest tag through the pipeline. Without SHA tags you can't identify or roll back to a specific build; confirm the pipeline tags by commit SHA.
- Skipping the runbook because "I know how it works." The runbook is what lets someone else (or future you at 2am) deploy and roll back; start it now, finish it on Day 161.
Q1. A push to main deploys to staging, but a teammate merged a PR whose eval gate was red. What is misconfigured?
Q2. Why rehearse a rollback on staging as part of this checkpoint?
Q3. What makes a "passed staging" result actually predictive of production?
Go deeper — curated resources
- Rehearse the customer pipeline demo — Script a 5-minute walkthrough — push a change, watch it gate, deploy, and roll back — for a customer's engineering lead. Day 167 grades demo craft and Day 169 covers change-management reviews; this is the artifact both want to see.
- Pipeline drawn from memory and diffed against the capstone; punch-list written
- Push-to-main runs test → eval-gate → build → deploy to staging end to end
- Eval gate blocks a sabotaged PR (required check verified); smoke test green from laptop
- Rollback to a previous SHA rehearsed and shown to revert staging
- RUNBOOK.md started; cumulative quiz ≥ 2/3 and due deck cleared
← Back: This checkpoint assembles Days 148–153 into one line and depends on the Day-147 observable service — you deploy something you can already trace, gate, and measure.
Forward →: Week 23 turns this staging pipeline into the Day-161 production cutover; Day 155–156 optimize the deployed service's latency and cost, Day 157 formalizes its monitoring into SLOs, and Day 158 turns today's rehearsed rollback into a full incident playbook.