Feature toggles in Trivia Crack (Part 1)
Feature Toggles (often also referred to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code. — Martin Fowler
Three years ago, the need arose to develop a new feature in Trivia Crack to be tested only in one country in order to see if there was an improvement in metrics such as retention and engagement, among others. If there was an improvement, we intended to make it available for all our players. It was the first time we faced this challenge since, up until then, features used to be developed and launched globally.
Our first experience with feature toggles
After some research, we found that the use of feature toggles would allow us to change the app’s behavior without altering the code. Therefore, if we wanted to enable the feature for one country and then expand it to the rest of the world, we would be able to do it with only a minor configuration change.
For new features, adding a feature toggle is simple. Since the entry point of a new feature is generally a new button on our dashboard, using a feature toggle around that entry point is enough.
What did we do?
- While the feature is being developed, the button doesn’t appear in the productive version of the app, even though part of the code is included.
- The button is only displayed to some of our users to make sure it works properly once the new feature is ready.
- This is the turning point: if the feature’s metrics are good, it means it’s ready to be launched for the rest of our players. If the metrics are not good enough, we can always make adjustments to improve it or to completely disable/delete it.
- If the feature is eventually made available for all users, the code related with the feature toggle is deleted and the button becomes permanently visible.
What types of feature toggles did we use?
Along with the inclusion of feature toggles for new features, we began to incorporate different types to modify and improve our app. The two feature toggles that we use the most are release and experiment toggles, although we incorporated the use of operational toggles for the migration of services as well.
The inclusion of release toggles allows us to continuously integrate incomplete features into productive code in order to control when these features are displayed to our players.
We use experiment toggles in order to perform A/B tests in our game: these include changing the game’s economy, UI elements and advertising formats, among other aspects.
We use operational toggles to carry out the migration of services in our back-end. By using these feature toggles, we make sure there’s no loss of availability: if the new service has loading issues, we can always rollback to the previous version.
Development process
Undoubtedly, the use of feature toggles has drastically changed the way we develop new features and has transformed the way we update, adapt and improve existing features. Among the main changes our development process faced, it’s worth mentioning the following milestones:
We stopped using long-running branches
For the development of features, every team used to keep a development branch parallel to the main branch. This branch used to be included in the productive code only after the team’s feature was ready for production. This dynamic wasn’t working for us because the long-running branch had to be constantly updated and the parallel branch’s merge could be messy. Trying to include hundreds of changes also led to compilation problems.
Using long-running branches works against the idea of continuous integration. Long-running branches aren’t necessary if feature toggles are implemented, since features are included in the productive code in a passive way.
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily — leading to multiple integrations per day. — Martin Fowler
We included gradual improvements to minimize risks
One of the great advantages we found in using feature toggles is that we are now able to implement improvements in our most important features and turn them off if there are any issues. This is especially true if we consider the fact that, in the mobile world, an application update is not an instant process, but one takes a few days to reach our players.
For example, there’s a mission module in Trivia Crack in which players have to complete objectives and receive coins as a reward. In the first version of the missions, players only had one task to carry out. The second version allowed them to complete a series of tasks and receive more rewards. We launched this version on a weekend and we identified a crash on Android and all we had to do to fix it was turn the feature off remotely.
Just as we constantly improve existent features, we started planning the development of features incrementally. For this purpose, we started out with a minimum version that would allow us to validate the user’s interest in order to add improvements that would make it easier to extend the behavior (possibly incompatible with previous versions) and finally disable previous obsolete versions.
We made the decision to remove irrelevant features
In the past, any feature in production had to be maintained for a considerable amount of time, or at least enough time for the latest version that supported the feature to have a minimum adoption.
With feature toggles, turning off a feature is an automatic process, which allows us to erase the code for the next release.
Conclusion
The use of feature toggles was our first step towards a continuous delivery oriented approach. Using these techniques allows us to speed up our development process and allows Trivia Crack’s six teams to carry out weekly releases in all our mobile platforms effortlessly. Feature toggles allow us to easily mitigate issues in each release and make it possible for each team to work more independently.
