“I experimented with feature toggles during the hackathon. Our hackathons give us the opportunity to present the things we want to change and to present working solutions to the team.”

You’re a developer. You want to optimize your product – and also the technologies, processes, and software at your company. So, it’s a no-brainer that you hail in-house hackathons as well as the opportunity to showcase functional prototypes to your team and receive feedback from them. With any luck, you’ll then get to implement your idea in practice. 

Last month, adjoe’s Go Backend Developer Davud Safarov and DevOps Working Student Maaz Malik paired up for adjoe’s first hackathon of the year. Together, they decided to integrate a release management software into the development cycle at adjoe. By doing so, they wanted to address the pain points numerous developers face when deploying new features.

A Feature Working in Test Environments but Failing in Production

When releasing new features, you’re always vulnerable to unexpected user inputs or making a mistake deep inside the code. If the mistake is significant enough, the changes need to be reverted as soon as a problem has been identified. A process that can take up to a few minutes. It may well take longer if this error affects a large percentage of your clients. 

With their hackathon project, Davud and Maaz wanted to make sure that adjoe avoided exactly these problems caused by features failing in production. The release management software that Davud and Maaz integrated – Flipt – provides you with a dashboard. This allows you to enable or disable features in production with a click of a button. By integrating the software, the developers also wanted to make use of dark launching techniques.

Deploy as Much as You Want

Integrating a release management software helps you avoid taking big business risks and disappointing clients. With this software, you can

1. adjust which percentage of your users will be able to see a new or experimental feature, 
2. perform A/B testing for that feature to assess whether the feature would be beneficial to clients and adjoe itself,
3. progressively deploy it to more users or more geographical zones and thereby avoid deploying a feature to all end users at once.

Developers – not just at adjoe – can also benefit from the capabilities of dark launching or beta releases. By incrementally deploying your features, you’ll be more confident when you release a new feature. Then, when you’re ready to launch on a larger scale, it’ll only take one click. With release management software, this step suddenly becomes significantly easier and quicker.

Release Management Software with Targeting Capabilities

By being able to decouple deployments from feature releases, you enable your product to have targeting capabilities without any extra effort. Without integrating an existing feature flag service, you can still build your in-house solution and enable certain features for an exclusive subset of partners. But you will ultimately be losing time and adding code complexity to your product.

Let’s say you want to optimize algorithms that determine how campaigns appear in adjoe’s Playtime offerwall. This would be a lot easier with release management software. Whether campaigns are sorted via CPI, margin, or profitability score, you can tailor your bidding model to suit certain partners. And once you know that you have a model that really works, you can deploy these optimizations on a larger scale. By doing this, you eliminate the risk of unnecessary revenue loss.

Example: Making an HTTP Request to the Feature Flag Service

After you have defined the flag and which partners you should expose to the profitability-based coin calculation algorithm in the dashboard, you can write your function that makes an HTTP request to the feature flag service, asking if the partner is in the experiment or not.*

* (code is simplified and does not reflect the full original code used at adjoe)

var profitabilityCalculationKey = "profitability-score-based-playtime-reward-calculation"
func (flip FlipFlagService) ShouldUseProfitabilityBasedCoinCalculation(partnerID string) bool {
    params := evaluate.NewEvaluateParams()
    params.SetBody(&models.FliptEvaluationRequest{
        FlagKey: strptr(profitabilityCalculationKey),
        Context: map[string]string{
            "PartnerID": partnerID,
        },
    })
    r, _ := flip.client.Evaluate.Evaluate(params)

    return r.Payload.Match
}

You can easily use this function for coin calculation and decide which algorithm should be used to calculate the coins for a campaign.

func (c CampaignService) calculateCoins(campaign Campaign) int64 {
    if c.experiments.ShouldUseProfitabilityBasedCoinCalculation(campaign.PartnerID)  {
        // calculate and return coin amount using new profitability-based algorithm
    }
    // calculate and return coin amount using the old way
}

Example 2: Targeting Test Devices for a New Offerwall Design

Here, Davud and Maaz selected who could see the new offerwall design; the targeted users are “adjoe test Devices.” Meaning that the new offerwall UI implemented by them will only be visible by the test devices owned by the company.

Avoid Wasting Time on the Revert Pipeline 

Integrating the right software with feature flags would mean developers like Davud and Maaz could deploy when and to whom they want. And much more frequently. They’d experience faster incident resolution thanks to kill switches – and also cut out a lot of the extensive communication and coordination needed between teams involved in the revert pipeline. No more team threads detailing what should be reverted, when a developer can tackle a fix, whether all external teams are ready for the release, and when the incident is finally resolved. 

Note: Quickly resolving a feature error by the feature toggle could in theory be managed by anyone in the company with access to the dashboard. For instance, anyone in adjoe’s Development, Product, or Business teams. You would not need knowledge of code to perform this incident resolution.

A Future of Feature Flags at adjoe

When Davud and Maaz opted to focus on release management software and feature toggles, they knew very well that this was not an adjoe-specific issue. But they did want to find an adjoe-specific answer and a working solution to show their team. And that’s exactly what hackathons are for. They looked at the market, picked flipt (a flag management service that was easy to set up), integrated it with adjoe’s product, and showed a fully working solution in a sandbox environment.

Davud and Maaz’s hackathon project brought to life a functional fix for a) optimizing adjoe’s partners’ performance, b) boosting adjoe’s business, and c) cutting important time spent on the revert pipeline. With its targeting capabilities, adjoe has already seen success in progressively deploying features for its partners. It could turn to release management software long-term as a means of boosting performance and team efficiency on a larger scale. So, it’s no wonder that the pair’s project received company recognition – and a reward.

It now remains to be seen which release management software adjoe will integrate its product with …