You better take that back! — Rollbacks are a Necessity

January 17, 2023 by Kim Loomis, Product Owner @ Fathym

In this article:

• Rollbacks are essential part of any development cycle
• Typically, rollbacks have been very difficult
• Modularity makes rollbacks easy
• Rollbacks are standard out-of-box feature with Fathym

Life Rollbacks

“You better take that back!”

I heard this countless times on the playground while playing [insert name of any game here]. I would say something or someone else would say something and we would all be talking “smack” about our opponents. In other words, trash talking, putting down their skills (or lack thereof) and very much trying to crush their dreams of winning.

The game would progress, the score would get closer, the play would get rougher. Someone would go too far, words would escalate into something too crazy, ridiculous, or personal, tempers would flare, the game would stop, and the “You better take that back!” gauntlet was thrown down. Usually, we were able to assuage each other’s hurt feelings, apologize (albeit begrudgingly) and go back to playing the game. We continued as we had before.

We rolled it back.

Product Development Rollbacks

Like in life, the “You better take that back” moment can happen in product development.

In the mid-1980s, the Coca-Cola Company introduced “New Coke”. It was a spectacular flop. The company changed the formula for Coke, consumers did not like it, nor did they take to the company messing with their venerable beverage, and Coke had to revert to the old recipe for Coke. The change was considered the “marketing blunder of the century” by some and the product was rolled back to its original version.

Software Development Rollbacks

The same happens in software development. A new application is rolled out or a new feature is rolled out, but something is not right. So, it needs to be pulled back and an older working version put back in place.

Different things could have happened that required a rollback. Something may just not work — it has bugs, fails to work, and gives error messages. Or something does not work as expected. It still works but the outcome is not what was intended.

Both are terrible user experiences, can lead to frustration and confusion on the part of the user, and the user may end up abandoning the application if fixes are not made quickly.

But not all fixes can be made quickly.

What can happen, though, is a rollback. Version 12 doesn’t work so it gets rolled back to version 11 which was the last working version. But rollbacks can also take time. So, now it becomes a wait and see game — possibly with no set time/date of when the rollback will fully reinstate the prior version. And, again, the user can experience frustration because the application still does not work.

Rollbacks are Arduous

Usually, it takes a lot to do a software rollback. A lot of time and money — which no one wants to spend; a lot of pain — which no one wants to endure to go backward; and a lot of complexity — how do you unravel the logic, the services, the functions, the data modifications and the UI changes that you just knitted into your application?

It becomes even harder when the application is a monolith. The rollback then translates to having to unwind something that is wrapped up in a large piece of software, one in which a change to one feature is going to affect changes everywhere else.

Let’s illustrate this: having a problem with a monolithic application is akin to getting a big wad of gum (the thing that doesn’t work) stuck in your hair (the monolith). You’re going to spend some time, effort and money to solve this problem.

You can’t just cut out the gum as the rest of your hair won’t look good with a chunk of it missing. So, you cut the gum out AND you must cut the rest of your hair to make it look presentable.

You can try to get the gum out and leave your hair intact. So, you slather on some peanut butter, vegetable oil, or vinegar (or all three), and meticulously work the gum out.

Your next problem is getting that stuff out of your hair. Only with a great deal of effort, materials and patience may that glob of gum come out and leave your hair as it was.

Modularity = Small Rollbacks

All joking aside, to help alleviate the possibility that a rollback of such magnitude is in your future, Fathym helps by modularizing your applications. Modularity is simply how smaller things are combined to make bigger things. With a modular approach, Fathym helps you create routes or subpaths or subdirectories on your application. Each webpage on a route is its own entity, developed and deployed apart from the others. Likewise, it is also capable of being rolled back without affecting the other routes and lessening the impact of the rollback on your organization.

In the picture above, a developer or development team can be making changes to the /admin. Maybe the team is changing the way permissions are set for data creation and viewing. Maybe the team is adding a new workflow process. Modularity means the changes to /admin are only going to affect /admin. The root path, /blog and /docs will all remain unaffected by the changes. /admin gets deployed with its changes. If something were to go wrong with the /admin changes, the rollback of those changes does not affect them either. Those parts of the application continue to work as normal.

Ending Experimentation

While rollbacks can be necessitated by unexpected problems, they may also be the end of deliberate experimentation with the application. For example, a company updates their user interface. The company theorizes that by changing the UI, it will improve interactions with the users, getting the users further through the company’s funnel and turning more users into subscribers.

Changes do not always work the way it is expected; that’s why they are called experimentation! The company lets the new interface run for some time. Upon hitting the end date, if analytics suggest the UI did not perform as well as it was wanted, or there is user pushback due the change, the new UI is yanked — or, more specifically, rolled back to a version that did perform better.

Rollbacks with Fathym

Regardless of the situation you find yourself in or the reason you have for doing a rollback, Fathym allows you to do them quickly and easily. It’s as simple as changing the version with a couple mouse clicks.

Once you are logged in and at your Fathym dashboard, you can navigate to the specific application that needs to be rolled back. You do this by navigating from Enterprise -> Project -> Application -> Route. The page to edit the version looks like this:

In this example, the application is at current version of 7 or latest. You can change that easily by editing the Build (if using GitHub) or Package Version (if using NPM) to a previous version.

Here, the rollback is to version 6. Note that it could be rolled back to any version in the past. The Save button is also enabled upon editing.

After a few minutes, the rollback has been saved and Version 6 is what will be in production.

And that is all there is to making a rollback with Fathym.

Rollback Simplicity with Fathym

Rollback is a standard out-of-the-box feature with Fathym.

Other platforms may not include a rollback feature at all, and you would need to resort to using separate rollback functionality. Or the rollback feature is complex, requiring time and effort to individually address services, data, and dependencies. With Fathym, it’s only a few mouse clicks and a different version is up and running.

Using Fathym, an organization has the confidence that if an issue were to arise with their application or they are done with an experiment, that it can be easily reverted to a working or previous version. The organization can preclude user frustration, poor public relations, and system downtime with the option to easily rollback with Fathym.