Chapter 29 — Capstone build
Lesson map
Lesson 29 published. Map, example, EX085.
flowchart TD
N0["Learning outcomes"]
N1["29.1 Capstone"]
N2["29.2 Criteria"]
N3["29.3 Build"]
N4["29.4 Testing"]
N5["29.5 Fixes"]
N6["29.6 Safety"]
N7["Repository layout"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX085"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["29.1 Capstone"]
N2["29.2 Criteria"]
N3["29.3 Build"]
N4["29.4 Testing"]
N5["29.5 Fixes"]
N6["29.6 Safety"]
N7["Repository layout"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX085"]
[Learning outcomes]
|
v
[29.1 Capstone]
|
v
[29.2 Criteria]
|
v
[29.3 Build]
|
v
[29.4 Testing]
|
v
[29.5 Fixes]
|
v
[29.6 Safety]
|
v
[Repository layout]
|
v
[Worked example] --> [Exercise EX085]
Learning outcomes
You will (1) combine course work into a capstone; (2) define success criteria; (3) build and test.
29.1 Capstone
Priya's capstone is a "client security baseline kit": inventory, baseline, pipeline rules, log alerts, runbooks. Each part of the kit comes from earlier work: the inventory script, the six-check baseline, the four pipeline rules, the alerts from the audit summary and the tested runbooks. Packaging them as a kit means a new client can be set up with the same checks in one session, rather than rebuilding each piece from scratch as Priya did during her placement. The kit therefore contains nothing that was not already tested during the placement.
29.2 Criteria
Success: runs on all clusters, under one hour to answer an advisory, runbooks tested by another person. Each of the three success criteria can be measured directly. Running on all clusters means the kit works on dedicated and shared clusters alike; under one hour for an advisory sets a limit well above the half-hour measured in evaluation, leaving room for harder cases; and runbooks tested by another person means the kit does not depend on Priya. Kwame agrees the three criteria with Priya before the build starts.
29.3 Build
She packages the scripts and documents in one repository folder with a readme. One folder keeps the scripts, baseline, rules, alerts and runbooks together, so they are reviewed and versioned as a set rather than drifting apart. The readme states what the kit does, the order of installation, the read-only access it needs and its limits. Priya writes the readme last, after the parts are finished, and then checks it against the folder contents. The folder is reviewed by Kwame before the install test begins.
29.4 Testing
A colleague installs the kit for a new synthetic client from the readme alone. Installing from the readme alone tests the documentation as much as the code, because the colleague cannot ask Priya questions during the install. The new client is synthetic, so the test touches no real systems. The colleague records each step where the readme was unclear, and those notes become the list of fixes before the kit is accepted. Priya stays out of the room during the install, so she cannot help by accident.
29.5 Fixes
Two unclear steps are rewritten. The colleague's notes identify two steps where the readme assumed knowledge the reader did not have, such as where to find the cluster's read-only credentials. Priya rewrites both with explicit instructions and links to the relevant runbook entries. The colleague then rereads the changed steps and confirms that they are now clear without further explanation. Neither rewrite changes the scripts themselves; both are documentation fixes only. The kit's changelog records the two changes with their date, so later maintainers can see why the steps read as they do.
29.6 Safety
The kit reads settings only and changes nothing. Reading only matters because the kit runs against client clusters, and a script that changed settings by mistake could break a client's service. Every script uses read-only access, and the peer review confirms that none writes to a cluster. Changes to client clusters still go through the pipeline and change windows, never through the kit itself. The readme states this rule at the top, so anyone installing the kit sees it first. The peer review record is attached to the kit's first release.
Repository layout
The kit folder contains scripts, the baseline file, pipeline rule definitions, alert definitions and runbooks, each in its own subfolder with a short readme. A top-level readme explains the order of installation and the access needed. Keeping everything together makes reviews easy and lets Cobalt version the kit as a whole.
Priya also adds a changelog so future changes are traceable.
Limits of the kit
The kit does not cover application code, client staff accounts or provider control planes. These are listed in the readme.
Synthetic test client
The test client is built from synthetic data, so no real client systems are touched during the test.
Maintenance
The platform team agrees to review the kit each quarter and after any Kubernetes version upgrade.
Peer review
Before the install test, a teammate reviews the scripts for clarity and confirms they only read data.
Time budget
Priya keeps a log of hours spent, useful for estimating similar kits for other clients.
Acceptance
Kwame accepts the kit after the install test meets all three success criteria.
Versioning
The first release is tagged version one.
Worked example
The colleague's install takes 50 minutes and passes all checks on the new client.
Synthetic case. Kit is synthetic.
Errors and limits
A kit tested only by its author may hide assumptions.
Exercises
- EX085 — Kit parts. What does the kit contain? Rubric: 3 = inventory, baseline, pipeline rules, alerts, runbooks; 2 = four; 1 = two; 0 = none.
- EX086 — Criteria. State the success criteria. Rubric: 3 = all clusters, <1h advisory, runbooks tested; 2 = two; 1 = one; 0 = none.
- EX087 — Install test. What was the install result? Rubric: 3 = 50 minutes, all checks passed; 2 = partial; 1 = vague; 0 = none.
Synthesis
Build, test with others and fix assumptions.
Continue studying — chapter 29 of 30
← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →