Chapter by Chapter
Where each chapter starts in the repository and the one command that confirms you finished it, plus the three things the labs need from you.
The repository is cumulative: each chapter starts from the state the previous one ended in, and the chapter's own validation command is what tells you the state is real.
Prerequisites arrive in three tiers, and no tier is needed before the chapter that uses it. Chapters 1, 2, 11 and 12 need only Python 3.11 or newer, Bash and Git; Chapters 3 and 4 add a container runtime and a repository of your own; Chapters 6 to 10 and 13 add a disposable cluster, for which a local kind cluster is enough.
| Chapter | Start from | Confirm with |
|---|---|---|
| 1 | An empty workspace/ you create | The chapter's own success and failure runs |
| 2 | reference-app/src, reference-app/tests | cd reference-app && python3 -m unittest discover -s tests |
| 3 | The pinned release tree | The chapter's docker build and label assertions |
| 4 | make delivery-start | actionlint .github/workflows/*.yml |
| 5 | The pinned release tree | terraform validate |
| Interlude | labs/cluster/, scripts/lab-environment/ | The interlude's own cluster and teardown checks |
| 6 | The pinned release tree | kubectl kustomize deployment/kubernetes/base |
| 7 | make gitops-start | kubectl kustomize deployment/gitops/overlays/staging |
| 8 | make observability-start | make observability-validate |
| 9 | make security-start | ./scripts/validate-offline.sh, labs/security/verify-security-ruleset.sh |
| 10 | make incident-start, then make capacity-start | make incident-validate, make capacity-validate |
| 11 | The pinned release tree | make assistant-validate |
| 12 | The pinned release tree | cd operations-agent && python3 -m unittest discover -s tests |
| 13 | make capstone-start | make capstone-validate |
Where the table says āthe pinned release treeā, that subject has no handoff tag cut yet, so git switch --detach v1.0.0 is the binding starting state. The paired make <subject>-complete puts you on the finished state, and the difference between the two is the work.
Three things the labs need from you
A chapter that appears not to work from Chapter 6 onward is usually one of these left unset:
- a disposable cluster in your
kubectlcontext; - a registry the cluster can pull from, with the image digest set in
deployment/kubernetes/base/kustomization.yaml; - a Git source Argo CD can reach and you can push to, set in
deployment/gitops/argocd/.
The published digest is an all-zero placeholder that cannot pull, which is deliberate: an unreplaced value fails at admission rather than deploying something you never reviewed.
The full guide, including the four rows that carry a condition the table cannot hold, is in the Downloads.
Errata, companion releases, and new notes on verifying AI-generated DevOps work.
Subscribe by emailOpens a pre-filled email to info@tafohpublishing.com. Send it and we will add you to the list. No spam, unsubscribe anytime.