Lesson 12 · Secrets, scale & operations

Chart quality

Catching a broken template before it reaches a cluster — lint, render, versioning, and the drift check.

Your win: name the tools that validate a chart (lint, template, schemas, versioning) and read this repo's actual quality posture — including where it relies on a drift check and where it has a gap.

The validation toolkit

Tool	Catches
`helm lint`	structural/best-practice problems in a chart
`helm template` (dry-run render)	template errors + lets you eyeball the YAML before deploy
`values.schema.json`	invalid/missing values, validated at install
chart `version` bumps	tells consumers a chart changed (SemVer)
`--dry-run` / `--debug`	a full server-side rehearsal of an install

The cheapest, highest-value habit helm template (render locally, no cluster) is the fastest way to catch the classic bugs — a mis-indented nindent, an undefined value, a bad toYaml. If it doesn't render, it was never going to deploy. Do it before every change lands.

This repo's quality posture — honest version

Anchor — what exists

helm template is used for rendering — e.g. deployments/job.bash:183 renders a job chart. And Course 1's skaffold render is a full helm template of the stack, so template errors surface in the deploy pipeline.
.helmignore is present in every chart (keeps junk out of helm package).
Versioning: charts carry version: 0.1.0 + appVersion (Lesson 2); the image tag is injected per-deploy via setValueTemplates (Lesson 8).

Anchor — the gaps (worth naming in an interview) Being honest about what this repo doesn't do is itself good engineering judgement:

No helm lint in CI — a grep of the scripts turns up none; the effective gate is "does helm template/skaffold render succeed."
Almost no values.schema.json — exactly one in the whole repo (appsmith/mongodb); backend services have none, so a typo'd value fails at render, not with a friendly schema error.
No drift check for the copied templates/util/ — you regenerate with make update-deps (Makefile:326), but there's no CI gate enforcing it.

The drift-check pattern the repo does use elsewhere

Anchor — generated-artifact guards The repo does guard other generated artifacts with a git diff --exit-code pattern — regenerate, and fail CI if the committed output differs: .github/scripts/ensure-make-generate-dags.bash (the Airflow DAGs, from that course) and .github/scripts/ensure-make-gen-db-schema.bash (the DB schema). That's the exact technique that would guard templates/util/ — a nice "here's how you'd close the gap" answer, and the shape of the drift check that keeps generated code honest.

Helm docs — Best Practices + helm lint / template

Chart conventions, and the lint/template validation commands.

→ helm.sh — Chart Best Practices
→ helm lint · helm template

Check yourself (from memory)

Q1. The fastest way to catch a template bug pre-deploy is…

Rendering locally surfaces indent/undefined-value errors with no cluster. If it won't render, it won't deploy.

Q2. A values.schema.json lets Helm…

It validates supplied values against a schema. This repo has just one (appsmith); backend charts rely on render errors instead.

Q3. The repo guards its generated DAGs/DB-schema with…

Regenerate then fail if committed output differs (ensure-make-*). The copied templates/util/ lacks this gate.

Chart validation tools + this repo's real quality posture.

recall, then click to reveal

VALIDATION: helm lint (structure/best-practice), helm template (render locally — cheapest, catches nindent/undefined-value bugs), values.schema.json (reject bad values at install), SemVer chart version bumps, --dry-run --debug. REPO POSTURE (honest): HAS — helm template in job.bash:183 + skaffold render, .helmignore everywhere, chart+appVersion. GAPS — no helm lint in CI, only ONE values.schema.json (appsmith), NO drift check on the copied templates/util/ (regenerate via make update-deps). The repo DOES use a git diff --exit-code drift check for DAGs + DB schema (ensure-make-*) — the same pattern that would guard templates/util/.

🎓 Course complete — all 12 lessons From "what Helm is" through chart anatomy, the template engine, values layering; then this repo's library-chart architecture (named templates, the copy model, hooks, Skaffold releases); then the production concerns (SOPS-in-app, values at scale, upgrade/rollback, quality). You've paid off Course 2's promise — you now know exactly how this codebase turns one library chart into ~106 charts of Kubernetes objects. Course 4 (Istio) is next, and it's Helm-deployed too — so it builds right on this.

Ready for Course 4 (Istio)? Or — nine courses' worth of lessons, still no retention check — let me run a mock interview on Helm and record where you're solid. Ask me.

1. Helm — Chart Best Practices; helm lint; helm template.