Companion · Tafoh Publishing
Thirteen projects that build a delivery platform you can defend: containers, pipelines, infrastructure as code, Kubernetes, GitOps, observability, security, incident response, and two bounded AI systems of your own.
The second edition is in preparation. This page is the companion: the repository, the route through the book, and an honest statement of what each chapter proves and what it does not.
Nothing in this book requires a cloud account or a paid tool. Each chapter states which tier it needs, so you can see the cost of a chapter before you begin it rather than four chapters later.
The method, the reference service, the operations assistant and the bounded agent. No containers, no cluster.
Images, continuous integration, delivery and rollback, and the security pipeline. Needs a repository you control.
Kubernetes, GitOps, observability, incidents and capacity. The interlude builds this cluster for you, and tears it down once so cleanup is rehearsed.
Chapters marked spine are the shortest complete path. Chapters marked optional teach a real capability you can read as design work and return to later. Every chapter can be started directly, because the repository can put your working tree in any chapter's starting state with one command.
| Ch | Project | Route | Time |
|---|---|---|---|
| Part I · Becoming an AI-Native DevOps Engineer | |||
| 01 | The AI-Native MethodA tested workspace and a prompt library with evaluation cases | spine | ~2h |
| 02 | Build the Reference ApplicationThe service every later chapter deploys, breaks and recovers | spine | ~2h |
| Part II · AI-Assisted Delivery | |||
| 03 | Containerize and OptimizeA multi-stage image that passes a documented release gate | spine | ~2.5h |
| 04 | CI and Delivery with GuardrailsGates that block a merge and gates that block a release, plus rollback | spine | ~2.5h |
| Part III · AI-Assisted Infrastructure and Platforms | |||
| 05 | Infrastructure as CodeA reviewed module and a plan you can read. No cloud account needed | optional | ~1.5h |
| — | Interlude: Bridge to the ClusterBuilds the lab cluster, enforces network policy, and rehearses teardown | setup | ~45m |
| 06 | Kubernetes with AI as a ReviewerDeclare a workload, restrict access, prove both the allowed and denied path | spine | ~2.5h |
| 07 | GitOps and Platform AutomationPromote one verified digest through review rather than a command | optional | ~2.5h |
| Part IV · Intelligent Operations | |||
| 08 | Observability with AIA telemetry contract wired to an alert and a runbook | spine | ~2h |
| 09 | AI-Assisted DevSecOpsFive evidence-producing gates and a policy written before the scan | optional | ~2h |
| 10 | Incident Response, Reliability and CostBreak it, recover through review, then optimize from the same baseline | optional | ~3h |
| Part V · Building Operational AI | |||
| 11 | A DevOps Operations AssistantRetrieval that cites its evidence and refuses when it has none | spine | ~1.5h |
| 12 | A Bounded Operations AgentTools without authority: least privilege, audit trail, human approval | spine | ~1.5h |
| 13 | Capstone: The Delivery PlatformTrace one release end to end, prove recovery, tear it down with evidence | spine | ~2h |
The reference implementation lives outside the printed book so it stays runnable and can be corrected without a new edition. Where the book and the repository disagree, the chapter map in the repository is correct.
labs/ holds one folder per chapter and one numbered file per printed block, so you can run a step instead of retyping it.
docs/chapter-map.md states what each chapter starts from, what it produces, how to validate it, and the gaps it does not close.
docs/running-labs-with-a-coding-agent.md lets an agent drive the labs while destructive and cost-bearing steps still stop for you.
docs/supported-versions.md and docs/release-policy.md state the tested baseline, how releases are tagged, and how long an edition's line is supported.
Working straight through is only one of them. The others are shorter, and none of them is a lesser reading of the book.
Every chapter states where its route stops. The cluster work is verified on a local Kubernetes cluster, so nothing here is evidence about a cloud provider. The infrastructure chapter reviews a plan rather than applying it against an account you pay for. The AI chapters run offline against fixtures, so they prove a boundary rather than a model under load. A capstone acceptance run is production-inspired, which is not a claim of production readiness.
Those limits are printed where the work begins rather than buried at the back, because a book that teaches you to ask what a green check actually proves should be willing to answer the question about itself.