How to: Perform a Hotfix Using Application Versioning

Overview

In this how-to guide, you'll learn how to use Unqork's Application Versioning feature to quickly and easily perform a hotfix in applications at the Production level. A hotfix is an update that corrects a specific problem in your application, like a failed API call or security vulnerability. This example is a desired best practice when creating a branch and fixing an application issue without affecting end-user experience.

Context

Let's set up a scenario where this situation might occur. Say you have a module in your versioned application that includes a Vega Table component. This component displays a Market Summary spreadsheet for vehicle insurance. The Vega Table includes the insurance carrier, type, premium (in USD), and the market status. It includes sorting and filtering logic that lets end-users easily locate relevant information.

Your team recently added the ability for end-users to add a new row to the table so they can dynamically enter values. The Vega Table component uses the TABLE_ADD_COLUMN operation that triggers the creation of a new row at the bottom of the table when the end-user clicks Add Row. The functionality was built in your Staging environment, and tested in QA and UAT. But, after promoting to your Production environment, this new functionality failed. When an end-user clicks the button, nothing occurs. To prevent interruption, and avoid having your end-users create multiple support tickets for a known issue, you decide to revert the Production application version to the previous one. That way, end-users won't see the nonfunctional button and your development team can explore the issue.

Perform a Hotfix

In this how-to guide, you'll explore the following steps to revert a Production-level application version from one that is not working correctly to one that is. The process involves using the Application Versioning feature to change the default version of an application at the Production level to a functioning one. After reverting to avoid end-user disruption, return to the broken application version in the Staging environment, and follow the standard SDLC practices. Do not correct the issue in the Production-level application version.

Revert the Default Application Version

The first step is to access the Application Versioning feature. Then, you'll revert the Production-level version to avoid disrupting your end-user's experience.

1. Navigate to your versioned application at the Production level.
2. At the top right of your Application page, click (ellipsis).
3. Select Promotions & Versions. You'll navigate to the Promotions and Versions page.
4. To the left of the page, select the Set Default Version tab. You'll navigate to the Set Default Version page.
5. Click Set Default Version. The Set Default Version modal displays.

A static image displaying the Set Default Version tab and the button to change the default version in your Production environment.

6. From the Select an Application Version drop-down, select the previous version, or one that you know functions correctly.

A static image displaying the Set Default Version modal where you can select a new Production-level version.

7. Click Confirm.

By changing the default version in the Production environment level, your end-users can automatically begin using the functioning application version. Following typical SDLC standards, your team can return to the new functionality created in the Staging environment, create a new branch, fix the issue, publish, test, and promote it to your end-users.

Resources