CD10: Capstone: three DevOps projects for RouteRani
Planning the capstone
🎯You'll be able to
Plan the capstone: scope, order of work, evidence and time.
🏠The everyday picture
A builder renovating a shop fixes the foundations and wiring first, then fits the shutters and the alarm, then the CCTV and the extra counters for the festival rush. Fitting CCTV before the walls are rebuilt means doing it twice.
📘What it really is
- The three projects, all in the RouteRani kit:
- An environment from code: a safe image, pinned providers, a generated password, a private database on a volume, two or more healthy
copies, no drift, and a rebuild from the files (10 tests in
npm run test:infra); - A pipeline with a way back: a safe GitHub Actions workflow and a pipeline script that tests, builds, deploys, verifies and rolls back
unhealthy, failing and slow releases (10 tests in
npm run test:pipeline); - Dashboards, alerts and scaling: Prometheus finding every copy, a Grafana dashboard, tested alert rules and an autoscaler with bounds
and a stabilisation window (8 tests in
npm run test:observe). -
Build in this order: Project 1 first (the pipeline needs
app_version,app_count, the outputs and zero-downtime replacement), then Project 2 (the autoscaler applies the version the pipeline records), then Project 3. -
Each project has acceptance tests in the kit and a marking guide on its project page. Add your own criteria too, such as "
terraform planshows no changes after every test run". -
Use this overview to judge your own work (each project page has the detailed marking guide):
| Area | What "good" looks like |
|---|---|
| Images | Pinned, slim, non-root, health-checked, starting the app directly (CD1) |
| Connected safely | Private database on a volume, stateless copies behind a load balancer, no secrets in files (CD2) |
| Infrastructure as code | Pinned, validated, no drift, rebuildable, safe replacements (CD3–CD4) |
| Platform judgement | A reasoned view on Kubernetes and a cloud design with access, network and cost (CD5–CD6) |
| Pipeline | Triggers, least privilege, pinned actions, gated deploys (CD7) |
| Delivery | Zero-downtime deploys, verification and automatic rollback (CD8) |
| Observable and scalable | SLIs, dashboard, tested alerts, safe autoscaling (CD9) |
📝A worked example
A learner's capstone plan (illustrative):
| Week | Work | Done when |
|---|---|---|
| 1 | Project 1: Dockerfile, .dockerignore, pinned providers, generated password |
Tests 1 to 3 of npm run test:infra pass |
| 2 | Project 1: volume, private database, copies, create_before_destroy, outputs |
All 10 pass twice in a row |
| 3 | Project 2: workflow fixes, version check, test stage | Tests 1 to 5 and 10 of npm run test:pipeline pass |
| 4 | Project 2: verify and rollback | All 10 pass; deploy and fault numbers recorded |
| 5 | Project 3: discovery, Grafana, alerts and their tests | Tests 1 to 5 of npm run test:observe pass |
| 6 | Project 3: autoscaler; capstone checks, demo, self-review and case studies | npm test shows 28 passed in one session; every project page saved as self-checked complete |
Doing Project 1 first meant the pipeline's rollback could read app_version from Terraform's outputs as soon as it was written.
🌍Where it's used
- Platform and DevOps teams taking over an environment with known problems.
- Reliability rescue work after outages.
- Portfolios for DevOps, cloud and SRE job applications.
📝Case scenario
A learner starts with the autoscaler because it seems most interesting. It writes app_count to a file, but the starter's Terraform has no
such variable and only one fixed container name, so every apply fails. They rewrite the Terraform for Project 1 and then have to change the
autoscaler again to read the new outputs. Starting with Project 1 would have avoided the rework.
🖱️Try it
Download the kit, follow routerani/README.md, and run npm test in tests/ once (about 15 minutes; most tests fail at this stage). Then write
your plan with a "done when" check for each week. Success: your plan lists all 28 tests across the three projects.
⚠️Common mistakes
- Starting without running the tests. Sign: no idea how far you are. Fix: run
npm testfirst and record what fails. - Leaving evidence to the end. Sign: no numbers for earlier work. Fix: save test output and load results as each project passes.
- Testing on a busy computer. Sign: timing tests fail at random. Fix: close heavy programs, and run a failing timing test again before changing code.
🛠️For your project
Run the kit's tests once before you plan, so you know what fails now: on the starter, 4 of the 28 pass: the formatting check, the second plan with no changes, destroy and rebuild (the starter's files are consistent, just unsafe), and Project 3 test 8, which passes only because nothing is running for the autoscaler to change yet.
✅Quick check
Why build Project 1 before Project 2?
Show the answer
The pipeline needs Project 1's variables, outputs and start-before-stop replacement to deploy and roll back.
What should you record as you go?
Show the answer
Test output and measurements for each project, saved as each one passes.