Lesson 11 · Secrets, scale & operations
Upgrade, rollback & releases
Every deploy is a numbered revision — so you can see history, roll back, and fail safely.
Your win: explain release revisions and history, how rollback
and --atomic work, and how this repo's Skaffold-driven, GitOps-ish model relates
to manual Helm rollback.
Revisions — the release's undo history
Every helm install/upgrade creates a new numbered
revision of the release, and Helm keeps the history (in those in-cluster
Secrets from Lesson 1).1 That history is what makes
Helm more than "kubectl apply with templates" — it's an account of what was deployed,
when.
| Command | Does |
|---|---|
helm history <rel> | list revisions (chart version, status, timestamp) |
helm rollback <rel> <rev> | create a new revision that restores an old one |
helm get manifest/values <rel> | see exactly what's deployed now |
helm upgrade --atomic --wait | auto-roll-back if the upgrade fails to become ready |
Rollback creates a revision — it doesn't erase one
helm rollback bob 4 doesn't delete revisions 5+; it applies the contents
of revision 4 as a new revision (say, 6). History is append-only — you can always
see that a rollback happened. And --atomic is the safety net: if a
--wait upgrade doesn't reach ready, Helm rolls it back for you automatically
instead of leaving a half-broken release.
How this repo actually rolls back
Anchor — revisions accrue from Skaffold, waits are built in
You don't run
helm by hand here — each skaffold run is a
helm upgrade --install (Lesson 8), so revisions accrue per service per env×org
namespace. The per-service release sets wait: true + statusCheck: true
(backend/bob/skaffold.yaml:24), so a deploy blocks until the
rollout is healthy (readiness probes, Course 2 L8) — the same "don't call it done until it's
ready" guarantee --atomic --wait gives.
GitOps-ish: the source of truth is git, not the cluster
In practice the "rollback" here is usually redeploy the previous state —
revert the image tag / values in git and let CI re-run Skaffold — rather than a manual
helm rollback. That keeps git as the single source of truth: the cluster is
whatever the last deploy rendered, and to change it you change git and redeploy. Manual
helm rollback still works for emergencies, but it makes the cluster diverge from
git until the next deploy reconciles it. (This is the deploy philosophy; the CI/CD
course covers the machinery.)
Drift: the cluster can silently diverge
Helm/Skaffold only reconcile when you deploy — this repo is push-based, not a
continuously-reconciling GitOps controller. So if someone
kubectl edits a live
object, it stays changed until the next skaffold run overwrites it. "The chart
says X but the cluster runs Y" is real; helm get manifest vs the rendered chart
is how you catch it.
Read this next
Helm docs — helm upgrade / rollback / history
Revisions, the rollback semantics, and the --atomic/--wait flags.
Check yourself (from memory)
Q1. helm rollback bob 4…
History is append-only: rollback restores old contents as a
new revision, so you can see the rollback happened.
Q2. helm upgrade --atomic --wait will…
If the waited rollout fails, Helm reverts automatically —
no half-broken release left behind.
Q3. In this repo, the usual way to "roll back" is…
Git is the source of truth; revert tag/values and re-run
Skaffold. Manual
helm rollback works but diverges from git.
Revisions, rollback/--atomic, and this repo's rollback-via-redeploy model.
recall, then click to reveal
Every install/upgrade = a numbered REVISION; Helm keeps HISTORY (in
in-cluster Secrets).
helm history lists them; helm rollback rel rev
restores an old revision's contents as a NEW revision (append-only — you see it happened);
helm get manifest shows what's live; --atomic --wait auto-reverts a
failed upgrade. REPO: each skaffold run = helm upgrade --install
(revisions accrue per service×env×org); wait:true+statusCheck block
until healthy. Rollback in practice = REDEPLOY prior state from GIT via CI (git = source of
truth), not manual helm rollback. DRIFT: push-based (not continuous GitOps), so a
live kubectl edit persists until the next deploy overwrites it.
Want to see how CI triggers a redeploy, or the difference between push-based and pull-based
(Argo/Flux) GitOps? Ask me — the CI/CD course goes deep on this.