Helm Roadmap
Five stages, each gated by a capability rather than a lesson count. Templating comes second on purpose: a template renders whatever won the values merge, and the release model is what every upgrade, rollback and diff actually operates on.
Dependencies that are not optional
Most lessons can be taken in any order within a stage. These four cannot.
- The release model before every upgrade behaviour Revisions, the release Secret and the stored manifest are what rollback, diff and the three-way merge all operate on.
- Values precedence before templating A template renders whatever won the merge. Debugging a template before you can predict the values is debugging the wrong thing.
- Whitespace and nindent before anything with a map in it toYaml piped into the wrong indent function is the single most common cause of YAML that will not parse.
- Hook semantics before migration design A rollback does not undo a hook. That one fact decides how every schema change in your system has to be written.
Stage 1 — Charts & Releases
~1hUnderstand what a release is before templating anything
Kubernetes fundamentals: you can read a Deployment and use kubectl. A cluster you can install into — kind is enough.
- ▸Name the three jobs Helm does, and which one a script cannot replace
- ▸Find a release's state with kubectl alone, and read a revision Secret
- ▸Say what every file in a chart is for, and why version and appVersion differ
- ▸Choose install, upgrade, rollback and uninstall flags deliberately
- ▸Predict which values source wins before running the command
Given a live release you did not create, you can state its current revision, the values it was installed with, the manifest it applied, and what a rollback would change — using only helm and kubectl.
Stage 2 — Templating
~1.5hWrite templates that render the way you intended
Stage 1. The values-precedence lesson in particular — templating a value you cannot predict is guesswork.
- ▸Use all five built-in objects, including .Capabilities and .Files
- ▸Control whitespace deliberately and choose nindent over indent correctly
- ▸Build a _helpers.tpl with the 63-character truncation and split label sets
- ▸Recover from the scope rebinding that with and range cause
- ▸Diagnose a failure at the right stage: values, render, API server or runtime
Handed a chart that renders invalid YAML, you find the cause with helm template --show-only in under a minute — and you can say which of the four stages every error you meet belongs to.
Stage 3 — Dependencies & Distribution
~1hPackage something other people can install and verify
Stage 2. A registry you can push to — GHCR, ECR or a local registry:2.
- ▸Declare dependencies with conditions, aliases and global values
- ▸Explain the coupling an umbrella chart creates, and when to split instead
- ▸Publish to an OCI registry and install by version or digest
- ▸Sign a chart and let a consumer verify it
- ▸Place hooks correctly and write chart tests that check the real contract
You publish a signed chart, install it from the registry into a clean cluster by version, and helm test passes — with a failing hook whose logs are still available to read.
Stage 4 — Production Operations
~1hSurvive the second deploy, and every one after it
Stages 1–3. Everything here is about state that already exists.
- ▸Explain the three-way merge, and why a kubectl edit is reverted
- ▸Recognise an immutable-field rejection and recover without an outage
- ▸Clear a release stuck in pending-upgrade without deleting the workload
- ▸Keep secrets out of values files, and know what SOPS does not protect
- ▸Choose pipeline-driven or GitOps delivery on drift detection, not preference
You can take a release stuck in pending-upgrade, decide between rollback and deleting the pending revision Secret, and recover it without a single pod restarting.
Stage 5 — Capstone
~1hProve the chart is operable, not merely renderable
Stages 1–4. The project assumes every one of them.
- ▸Build a chart with a schema, a conditional subchart, hooks and real tests
- ▸Publish it signed, and install it as a consumer would
- ▸Run nine drills including the four that only fail under failure conditions
- ▸Write the operations note that says what a rollback does not undo
Project — a colleague configures your chart for a new environment without opening templates/, and your drill log shows an atomic rollback, an immutable-field recovery and a retained hook failure.
Scope, and what changes underneath it
This path is written for Helm 3. A large share of
the Helm material still in circulation describes Helm 2, which reached end of life in 2020 —
the quickest way to date a document is to search it for helm init or Tiller.
Where a lesson quotes a default, verify it against your own installation rather than trusting
any document, including this one:
helm version and
helm show values <chart> settle most
disagreements in seconds.