Release Revisions and History

Release Revisions and History refers to the systematic tracking and management of all changes made to a Helm release over time. Each Helm release is assigned a revision number which increments every time the release is upgraded, rolled back, or otherwise modified. This revision history enables users and operators to audit changes, troubleshoot issues, and revert to previous stable states if necessary.

Overview of Release Revisions

Definition of a Revision

A revision represents a snapshot of a Helm release’s manifest and configuration at a particular point in time. It captures the exact state of resources deployed in the Kubernetes cluster, including all manifests rendered from the Helm chart templates and the values used during deployment.

Revision Numbering

Revisions are sequentially numbered starting from 1 when a release is first installed. Each subsequent upgrade or rollback increments the revision number by one, preserving a linear history of changes associated with that release.

Purpose of Revisions

• Auditability: Revisions provide a detailed log of what changed, when, and why.
• Rollback: They allow reverting to a previous release state if an upgrade causes issues.
• Troubleshooting: By comparing revisions, operators can identify configuration or manifest changes that introduced bugs or failures.
• Version Control: Revisions act as a native versioning system for deployed applications within Kubernetes.

Accessing Release History

Helm CLI Command: helm history

The primary method to view release revisions is through the helm history command, which lists all revisions of a release along with metadata:

helm history <release-name>

This command outputs a table with the following columns:

• REVISION: The revision number.
• UPDATED: Timestamp of the change.
• STATUS: Status of the release for that revision (e.g., deployed, superseded, failed).
• CHART: The Helm chart version used.
• APP VERSION: The application version from the chart metadata.
• DESCRIPTION: Summary of the action performed (install, upgrade, rollback).

Detailed Revision Information

To inspect a specific revision’s manifests and values, the command:

helm get manifest <release-name> --revision <revision-number>

or

helm get values <release-name> --revision <revision-number>

can be used to extract the exact Kubernetes resource definitions and configuration values applied at that revision.

Managing Release History

Rollbacks

Using the release history, Helm allows rolling back a release to a previous revision with the command:

helm rollback <release-name> <revision-number>

This reverts the deployed resources to the state captured at the specified revision, enabling quick recovery from errors introduced in newer versions.

History Retention and Cleanup

Helm stores release revisions in the cluster as ConfigMaps or Secrets (depending on Helm version and configuration). Over time, these can accumulate, potentially impacting storage and performance. Helm provides options to limit the number of stored revisions per release via configuration flags during install or upgrade, e.g.:

helm install --history-max 10 <release-name> <chart>

This limits the stored revisions to the 10 most recent, pruning older entries automatically.

Revision Statuses and Their Meaning

• deployed: The revision is currently active in the cluster.
• superseded: A newer revision has replaced this one.
• failed: The installation or upgrade failed at this revision.
• pending-upgrade: The release is in the process of being upgraded.
• pending-rollback: A rollback is currently underway.
• uninstalled: The release has been deleted.

Understanding these statuses helps interpret the release history and troubleshoot release states.

Practical Use Cases of Release Revisions and History

Continuous Delivery Pipelines

In automated CI/CD pipelines, tracking release revisions enables controlled rollouts, automated rollbacks on failure, and audit trails for compliance.

Disaster Recovery

In cases of misconfiguration or application failure, operators can use the history to restore a known good state quickly without manual redefinition of manifests.

Change Auditing and Compliance

Release history serves as a record of deployment changes, useful for security audits and regulatory compliance, capturing who deployed what and when.

Debugging and Incident Response

By comparing manifests between revisions, developers and operators can identify the root causes of incidents introduced by configuration or application changes.

Summary of Key Commands for Release History

Release revisions and history are fundamental features of Helm that provide robust lifecycle management for applications deployed on Kubernetes, ensuring traceability, recoverability, and operational control over Helm-managed resources.