CD10: Capstone: three DevOps projects for RouteRani
Demo, self-review and case studies
🎯You'll be able to
Demo the work, review it honestly against the marking guide and write a short case study for each project.
🏠The everyday picture
After installing a fire system, the engineer shows the owner the sprinkler valve, sets off a test alarm, and pulls the power to show the battery backup working. Showing what happens when something fails is part of the handover.
📘What it really is
- Demo (a recorded video of 10 to 15 minutes):
- Project 1:
terraform destroyandapplyrebuilding everything, a booking surviving a database replacement, a copy removed by hand and repaired by the next apply; - Project 2: a deploy under load with 0 failed requests, then an unhealthy release rolled back by itself;
- Project 3: the dashboard during load, the error alert firing for a bad release, the autoscaler scaling up and back down;
-
the full
npm testrun with 28 passing. -
Self-review against the marking guides: "met", "partly" or "not yet" for each area, with evidence: test runs, load numbers, plans and logs. Honest gaps with a plan are more useful than claiming everything is met.
-
Written design notes: how RouteRani would run in a cloud (CD6: region, zones, network, access, illustrative cost), whether Kubernetes would help and when (CD5), and how state would be shared in a team (CD4).
-
Case studies: one per project, with the problem, the approach, results in numbers and what you'd do differently. Label every figure as a result from the practice kit, with the date and the computer it ran on.
-
Repository tidiness: a README with setup and test steps; no state,
.tfvarswith secrets or.envfiles committed; clear commit history.
📝A worked example
A learner's self-review, in part (illustrative):
| Area | Rating | Evidence |
|---|---|---|
| Infrastructure as code | Met | 10 of 10 infra tests twice; destroy and rebuild shown in the demo |
| Delivery | Met | 10 of 10 pipeline tests; 0 failed requests in a deploy under load; three rollbacks recorded |
| Observable and scalable | Met | 8 of 8 observe tests; dashboard screenshot during load; autoscaler log |
| Pipeline | Partly | Workflow passes the local checks; not yet run on GitHub |
| Platform judgement | Partly | Cloud design and cost table written; Kubernetes YAML written but not run |
The "Partly" items came with a plan: push to a private GitHub repository with a self-hosted runner, and try the YAML on a kind cluster.
🌍Where it's used
- Handover to a new team or client.
- Job applications and interviews, where "show me a rollback" is a common request.
- Readiness reviews before a launch or a big event.
📝Case scenario
In a demo with three API copies running, a reviewer asks the learner to run docker rm -f on two of them while traffic flows. nginx retries on the remaining copy, the
load tool shows a handful of slow requests but no failures, and the next terraform apply brings the copies back. The reviewer notes it as the
strongest evidence in the portfolio: the learner understood what each part does when something breaks.
🖱️Try it
Record your demo, complete the self-review with evidence, tidy the repository, and write three case studies and the design notes. Ask someone to break something (stop the database, remove a copy, deploy a bad release) while you show what happens.
⚠️Common mistakes
- A demo that only shows the happy path. Sign: no failure shown. Fix: show a failure and how the system handles it.
- Claiming checks you didn't run. Sign: "works on GitHub" or "works on Kubernetes" with no evidence. Fix: say "not verified" for anything you couldn't run.
- Unlabelled numbers. Sign: figures with no date, computer or source. Fix: label every figure as practice-kit data, with when and where it was measured.
🛠️For your project
Record your results on each project page; the completion record collects them.
✅Quick check
What should a DevOps demo show besides the happy path?
Show the answer
A rebuild from code, a bad release rolled back, an alert firing, scaling up and down, and something broken on purpose.
What makes a strong case study?
Show the answer
A clear problem, the approach, results in numbers labelled as practice-kit data, and an honest note on what you'd change.