Hello, my name is Ilia, I’m Android Engineer. Almost three years ago, we started our fintech project. MVP deadline was very optimistic. A week before the release, our team realized that no one was going to postpone the start date, and one feature was unlikely to be completed on time. We didn’t want to take risks and it was decided to cover this part with a stub. By blocking part of the non-working functionality, we had hopes that the MVP scope would be closed. We planned to disable non-working code so that at the click of the CI / Web button, the screen became available to the user.
Step by step, our team increased. Many developers didn’t understand what the system was. The guide was required for the in-house team too. For this reason, we decided to create a separate library. But it wasn't enough… And the development process was modified too.
To be honest, the talks about FeatureToggle integration was a very long time. That story was a trigger.
FeatureToggle - is a development instrument that gives the possibility to disable/enable some features depending on the configuration.
A is available for developers, enabled for QA team, but disabled for Users.
With this tool, you can switch from GitFlow to TBD(IMO, without FeatureToggle it is impossible)
Until we lift the lid, we won't know what's in the pan.
**A/B testing** Let’s suppose that we have a hypothesis, that all users love to eat burgers. But, our manager doesn’t think so. In his opinion, all users love hot-dogs. And only the target user will help us to resolve this dispute. Ok, we might create a questionnaire on the main page or open a marketing company. But it will be so distracting to user and it will be impossible to create and manage many hypotheses. A/B testing it’s a solution that might solve that problem invisibly to user. ****Just split our users into 2 groups: burger lovers and hot-dog lovers. All clicks to the food banner have to be marked with analytics events. In advance with the manager the criteria for the success of the experiment and the conditions under which the experiment should be stopped. Then all clicks to the burger banner are put into the burger-analytics-event bucket, and the same story with hot-dog.
It is not necessary to have only 2 conditions for the experiment. A hypothesis can contain multiple inputs and outcomes.
Usually, data analysis is performed on the side that is responsible for issuing them. In our case, this will be the backend, and the client developers paint the buttons. It is only an example. The more realistic picture for the client story - is how that banner will be represented: vertical list, horizontal list, grid layout or custom big banner.
Remote control Let’s continue to talk about our hypothesis. Just imagine, that we created 10th variations for an experiment. One of them have an incorrect implementation and all users with that variation crashed. To solve that problem, usually, we have to create a bugfix ticket and wait until these users update our application. Of course, in-app update must help to solve it faster. But solving that problem might spend more than one week. One week of downtime for 10th percent of users - too much. There is no need to immediately interrupt the rollout for all users and solve problems. All that we want is to disable failed configuration remotely and continue bugfixing in state mode. The new config will be downloaded as soon as possible and the application will not be crashed anymore. Let us leave this condition as obligatory for the formation of our system.
Testing If we have a possibility to disable one part of the code by feature flag, we might to hide some part of the functionality from other eyes. The same assembly will contain several implementation variations. By that reason, when we pass the build to the QA team, we will write a guide on how to switch feature toggles. To make a possibility to check all variations. The same behavior awaits the next chain - internal,alpha, beta, release.
Now we know everything that we need to start cooking the FeatureToggle. Let’s form all necessary requirements to determine what we have to receive as a result. The system must have the possibility to force functionality, set flexible configurations, override values for different build types and have a remote control. In addition, add required system scalability and protection from unnecessary configuration falling into the wrong hands.
Feature flags can be toggled in the following ways:
FeatureToggle values. That solution will be more elegant than hardcoded values.data class FoodFeatureToggle(
val foodType: FoodType = FoodType.BURGER,
) {
enum class FoodType {
BURGER,
HOTDOG,
;
}
companion object {
val DEFAULT = FoodFeatureToggle()
}
}
//....
fun showFood() {
val featureToggle: FoodFeatureToggle = FoodFeatureToggle.DEFAULT
when(featureToggle.foodType) {
FoodFeatureToggle.FoodType.BURGER -> showBurger()
FoodFeatureToggle.FoodType.HOTDOG -> showHotdog()
}
}