Building a Deployment History of Four Revisions

Goal

You create four revisions yourself — install, upgrade, failure, and rollback — and check where and in what form Helm leaves that history in the cluster.

Why it matters

Helm 3 has no server component resident in the cluster. Then where does "which revision this release is at now" live — it lives in a Secret in the namespace where the release is installed. Its name is sh.helm.release.v1.<릴리스이름>.v<리비전> (release name and revision), its type is helm.sh/release.v1, and inside it the chart metadata, rendered manifest, values, and status are stored compressed. Because one Secret accumulates per revision, the deployment history remains in the cluster itself. There are two things you must learn by doing. First, a failed upgrade also remains as a revision — the status is recorded as failed and the real objects are kept exactly as they were. Second, a rollback does not undo; it creates a new revision — if you roll back to revision 2, the number does not return to 2, and a new revision 4 is created. Revisions only ever move forward.

Steps

Create a chart in /root/helm/rel/lab-app (helm create lab-app is enough) and install it in the namespace helm-lab with the release name lab-app: helm install lab-app /root/helm/rel/lab-app -n helm-lab --create-namespace --set replicaCount=1. This is revision 1. There must be one Deployment carrying the label app.kubernetes.io/managed-by=Helm in helm-lab. Also create the output directory /root/helm/rel/out in advance.
Make revision 2 with helm upgrade lab-app /root/helm/rel/lab-app -n helm-lab --set replicaCount=3. Then save the user values applied to that revision to /root/helm/rel/out/rev2-values.json (helm get values lab-app -n helm-lab --revision 2 -o json). The file must be valid JSON and replicaCount must be 3.
Save the history with helm history lab-app -n helm-lab -o json > /root/helm/rel/out/history.json. There must be 2 or more revisions, each entry must have the fields chart, app_version, and status, and at least one revision must have the status superseded.
Deliberately do one upgrade that renders fine but is rejected by the API server: helm upgrade lab-app /root/helm/rel/lab-app -n helm-lab --set replicaCount=abc. replicas must be an integer, so the manifest is rejected. Save the output, including standard error, to /root/helm/rel/out/failed.txt (> /root/helm/rel/out/failed.txt 2>&1). This is revision 3; its status remains failed, and the actual Deployment's spec.replicas must stay at 3. Do not attach --atomic — if you do, it rolls back automatically and you cannot observe the failed revision.
Go back to the state of revision 2 with helm rollback lab-app 2 -n helm-lab. This is revision 4. The latest revision number in the history must be 4 or more, the description of that revision must include rollback, the status must be deployed, and the actual Deployment's spec.replicas must be 3.
Save helm get values lab-app -n helm-lab -a -o json > /root/helm/rel/out/all-values.json and helm get values lab-app -n helm-lab -o json > /root/helm/rel/out/user-values.json respectively. The full values file must have 3 or more top-level keys and include image, and the user values file must have fewer keys than that.
Check the release Secrets with kubectl get secret -n helm-lab -l owner=helm. There must be as many as the number of revisions (4 or more), with type helm.sh/release.v1 and names in the form sh.helm.release.v1.lab-app.v<리비전> (with the revision number in the placeholder). Write what you confirmed in one or two lines in /root/helm/rel/out/storage-note.txt — it must say in which namespace and in what kind of object the release state is stored.
Create /root/helm/rel/out/report.json. It has four keys. revisions is an array holding the revision and status of each revision, which must equal the actual number of history entries and must include an entry whose status is failed. current_revision is the current latest revision number, rolled_back_to is 2, and deployed_replicas is the current Deployment's spec.replicas value.

Notes

Lab Pods start fresh for every lab, so charts or releases made in other labs do not remain. You build both the chart and the namespace here from scratch — this is where the fact that a chart is a reproducible package shows.
helm history, helm get values, and helm status all need the namespace given with -n. Helm remembers releases per namespace.
With -a (--all), the final values merged with the chart defaults come out, and without it, only the values the user actually passed. What separates "is this a default or a value someone put in?" during incident response is this difference.
The default number of retained revisions is 10, adjustable with --history-max. This is why Secrets do not pile up infinitely.
Common mistake 1: saving without 2>&1 in step 4, so the file is empty. The failure message comes out on standard error.
Common mistake 2: expecting the revision number to go back to 2 after a rollback. A rollback creates a new revision computed from revision 2's chart and values.

Make revision 1 with the first install

Create a chart in /root/helm/rel/lab-app (helm create lab-app is enough) and install it in the namespace helm-lab with the release name lab-app: helm install lab-app /root/helm/rel/lab-app -n helm-lab --create-namespace --set replicaCount=1. This is revision 1. There must be one Deployment carrying the label app.kubernetes.io/managed-by=Helm in helm-lab. Also create the output directory /root/helm/rel/out in advance.

Releases are remembered per namespace. To install into a namespace that does not exist, you can create it in advance or create it together with an install option. The replica count starts at 1.

Make revision 2 with an upgrade

Make revision 2 with helm upgrade lab-app /root/helm/rel/lab-app -n helm-lab --set replicaCount=3. Then save the user values applied to that revision to /root/helm/rel/out/rev2-values.json (helm get values lab-app -n helm-lab --revision 2 -o json). The file must be valid JSON and replicaCount must be 3.

Change just one value and deploy again. Then extract the user values applied to that revision as JSON and save them. There is an option that points to a specific revision.

Leave the release history as JSON

Save the history with helm history lab-app -n helm-lab -o json > /root/helm/rel/out/history.json. There must be 2 or more revisions, each entry must have the fields chart, app_version, and status, and at least one revision must have the status superseded.

The history holds the status and chart information for each revision. Check what the previous revision's status changes to when a new revision comes up.

Create a failing upgrade

Deliberately do one upgrade that renders fine but is rejected by the API server: helm upgrade lab-app /root/helm/rel/lab-app -n helm-lab --set replicaCount=abc. replicas must be an integer, so the manifest is rejected. Save the output, including standard error, to /root/helm/rel/out/failed.txt (> /root/helm/rel/out/failed.txt 2>&1). This is revision 3; its status remains failed, and the actual Deployment's spec.replicas must stay at 3. Do not attach --atomic — if you do, it rolls back automatically and you cannot observe the failed revision.

Just put in a value that renders fine but that the API server rejects. Try putting a non-integer value where the replica count goes. The error comes out on standard error, so you must capture it too when you save.

Roll back to revision 2

Go back to the state of revision 2 with helm rollback lab-app 2 -n helm-lab. This is revision 4. The latest revision number in the history must be 4 or more, the description of that revision must include rollback, the status must be deployed, and the actual Deployment's spec.replicas must be 3.

A rollback does not turn the number back; it creates a new revision. After the rollback, check together the latest number in the history and the replica count actually deployed.

Compare user values and all values

Save helm get values lab-app -n helm-lab -a -o json > /root/helm/rel/out/all-values.json and helm get values lab-app -n helm-lab -o json > /root/helm/rel/out/user-values.json respectively. The full values file must have 3 or more top-level keys and include image, and the user values file must have fewer keys than that.

If you add one more option to the same command, the result merged with the chart defaults comes out. It is normal for the two results to have different numbers of keys.

Check where the release is stored

Check the release Secrets with kubectl get secret -n helm-lab -l owner=helm. There must be as many as the number of revisions (4 or more), with type helm.sh/release.v1 and names in the form sh.helm.release.v1.lab-app.v<리비전> (with the revision number in the placeholder). Write what you confirmed in one or two lines in /root/helm/rel/out/storage-note.txt — it must say in which namespace and in what kind of object the release state is stored.

Helm 3 has no server resident in the cluster. Then where is the state? If you filter by label, you will see as many as the number of revisions.

Produce a lifecycle report

Create /root/helm/rel/out/report.json. It has four keys. revisions is an array holding the revision and status of each revision, which must equal the actual number of history entries and must include an entry whose status is failed. current_revision is the current latest revision number, rolled_back_to is 2, and deployed_replicas is the current Deployment's spec.replicas value.

Extract the numbers from the history and the actual deployment state and organize them as JSON. You must not leave out the failed revision, and do not write the numbers by hand; read them from command output and put them in.