How Class 101 developers transformed the way they worked Hackle’s Feature Flags

Class 101 is South Korea’s No. 1 online learning platform where creators and learners can come together. Due to its immense popularity, Class 101’s developers are responsible for over 3,000 cumulative products and services, 3.82 million members, 117,000 creators, and 66.5 billion won worth of creator content.

(After using Hackle’s Feature Flag) By the metrics:

• From risky deployments affecting 3.82 million users to safe deployment & releases several times a day
• From a 20 minutes long process of rolling-back faulty releases to an immediate roll-back response with the feature flag’s kill switch
• From deploying new features to 100% of real users to targeting feature releases for a fine-tuned segment of users

From risky deployments to safe deployment and release with feature flags

As a team that places importance on CI/CD and speed, Class 101’s tech team is oriented towards periodic distribution. However, in the past, frequent deployments (without feature flags) where new features were released immediately to real users caused a lot of service failures. Whenever an error occurred with a feature that was already deployed, there was a direct impact on negative customer experiences. However, with the safety of Hackle’s Feature Flag that could be attached to each deployed feature, they were able to resolve any incidents that occurred in production by “rolling back” a specific deployed feature with the kill switch from Hackle’s Feature Flag.

Even today, Class 101 continues to deploy new features daily, even several times a day, however with Hackle’s Feature Flags, they are able to do so without the risk of failure.

The problems with in-house feature flags with limited capabilities

Initially, Class 101’s developers used a tool called Redis in order to create their own feature flags to add to new features during the process of releasing to their users. These added feature flags to features allowed them to control whether the feature should be rolled out to users via an on/off tool.

However, there were two major problems at the time. First, since the feature flag was a switch that turned the feature on/off for all users when the feature was turned on, the feature was shown to 100% of their users. Due to this, Class 101 experienced system errors in cases where they couldn't target and roll-out their features to a specific segment of users. Secondly, there was a problem with the lack of employee access and permission management. As the system was built on the administrator side, the feature flags were accessible to any general company employees who were not developers. This led to a high risk of releasing or turning off features that had a direct impact on Class 101’s users.

However, the biggest reason for buying SaaS rather than building a feature flag internally was due to the number of internal resources that went into the maintenance process which could have been spent elsewhere such as for services that optimized their customer experiences.

The switch to Hackle’s Feature Flags with a high degree of targeting

Class 101 enjoyed the user targeting function of Hackle’s feature flag. They were able to set different on/off rules based on specific user agents such as “users who are yet to use a specific service” and “users who have already used a specific service” use. For example, Class 101 recently added a Korean mobile payment system, Kakao Pay, as a payment method. In the case of their mobile in-app users, Class 101 used the feature flag by turning off the feature for in-app users. It was a big advantage to be able to turn on/off features to detailed segments of users through Hackle without deployment. The reliability of Hackle allowed them to make important decisions, especially in cases where features have to be rolled back in case something goes wrong.

Moreover, Class 101 was also able to edit the targeted groups within a specific feature flag. For example, when they released a new feature for all users using a feature flag, they realized later on that the feature posed to be a problem for in-app users, and hence without rolling back for all users, they were able to simply edit the targeting settings within the feature flag by eliminating the in-app users.

Hackle’s dashboard is split into two, production and development

In most cases, developers like to test out their new features in the development environment or the “safe” workspace before releasing anything live in the “live” production environment. However, it is cumbersome to set feature flags in both the production and development environment, each time a new feature is being released.

However, Hackle’s dashboard supports both the development and production environments where developers can easily deploy to production with confidence after testing out the features with feature flags in the development environment.

Hackle’s Feature Flags helped Class 101 reduce risk during the deployment process of releasing multiple features simultaneously in production

There was a situation where Class 101 developers had to release multiple features immediately to the online user community page or to production where there was a direct impact on their customers, however, the developers deemed that it was risky to release all the features to production. Hence, deployment of multiple features to production was carried out using Hackle’s feature flags.

Check out Hackle at www.hackle.io in order to start your own fast and safe deployment process with Hackle’s feature flags.

Click here to find out more about the importance of feature flags for the deployment process of developer teams of all shapes and sizes.