No matter how we deploy our applications and no matter how much we trust our validations, the truth is that sooner or later we'll have to roll back. That is especially true with third-party applications. While we could roll forward faulty applications we developed, the same is often not an option with those that are not in our control. If there is a problem and we cannot fix it fast, the only alternative is to roll back.

Fortunately, Helm provides a mechanism to roll back. Before we try it out, let's take a look at the list of the Charts we installed so far.

 1  helm list

The output is as follows.

NAME    REVISION UPDATED     STATUS   CHART          NAMESPACE
jenkins 2        Thu May ... DEPLOYED jenkins-0.16.1 jenkins

As expected, we have only one Chart running in our cluster. The critical piece of information is that it is the second revision. First, we installed the Chart with Jenkins version 2.112, and then we upgraded it to 2.116.

We can roll back to the previous version (2.112) by executing helm rollback jenkins 1. That would roll back from the revision 2 to whatever was defined as the revision 1. However, in most cases that is unpractical. Most of our rollbacks are likely to be executed through our CD or CDP processes. In those cases, it might be too complicated for us to find out what was the previous release number.

Luckily, there is an undocumented feature that allows us to roll back to the previous version without explicitly setting up the revision number. By the time you read this, the feature might become documented. I was about to start working on it and submit a pull request. Luckily, while going through the code, I saw that it's already there.

Please execute the command that follows.

 1  helm rollback jenkins 0

By specifying 0 as the revision number, Helm will roll back to the previous version. It's as easy as that.

We got the visual confirmation in the form of the Rollback was a success! Happy Helming! message.

Let's take a look at the current situation.

 1  helm list

The output is as follows.

NAME    REVISION UPDATED     STATUS   CHART          NAMESPACE
jenkins 3        Thu May ... DEPLOYED jenkins-0.16.1 jenkins

We can see that even though we issued a rollback, Helm created a new revision 3. There's no need to panic. Every change is a new revision, even when a change means re-applying definition from one of the previous releases.

To be on the safe side, we'll go back to Jenkins UI and confirm that we are using version 2.112 again.

 1  kubectl -n jenkins 
 2      rollout status deployment jenkins
 3
 4  open "http://$ADDR"

We waited until Jenkins rolled out, and opened it in our favorite browser. If we look at the version information located in the bottom-right corner of the screen, we are bound to discover that it is Jenkins ver. 2.112 once again.

We are about to start over one more time, so our next step it to purge Jenkins.

 1  helm delete jenkins --purge