01 Nov

Launched: Android Feature Flags SDK

LaunchDarkly’s mission is to be your complete solution for enterprise feature flag management. We wanted to provide SDKs for every major language and platform, both web and mobile — allowing our customers to manage features and synchronize rollouts across multiple platforms.

Now, we are excited to announce the launch of our Android SDK (beta). This SDK supports both boolean and multivariate feature flags, allowing you to take full control over any feature or configuration in your release.

LaunchDarkly Android Mobile SDK for Feature Flags / Feature Toggles

Additionally, we wanted to ensure that the SDK always served the latest stored flag rules for each user, even if the app was backgrounded or if the app had multiple users on the same device.

To do this, we integrated some neat features: (these features are also available in our iOS SDK)

Android SDK Features

  • Simple User Construction
    • Easily construct users by using a builder pattern.  This makes it easy to use our targeting rules to perform custom rollouts by user key or any attribute.
  • Multiple User Contexts on One Device
    • If your app is used by multiple users on a single device, you may want to change users and have separate flag settings for each user. To achieve this, the SDK will store the last 5 user contexts on a single device, with support for switching between different user contexts.
  • Real-Time Updates
    • You can immediately kill bad features and have granular control over the timing of flag updates.  LaunchDarkly manages all flags for a user context in real-time by polling flags based on a real-time event stream. When a flag is modified via the LaunchDarkly dashboard, the flag values for the current user will update almost immediately.
  • Offline Mode & Background Fetch
    • We wanted to make sure that developers had full control over the offline and backgrounded behavior of LaunchDarkly.  If a user’s device is in airplane/flight mode or if they are not connected to a network, LaunchDarkly will use the latest stored flag settings in memory.  Additionally, when the app is backgrounded, the Android SDK does not receive real-time events. However, a battery-conscious Android Alarm is set to poll for updates once every 5 minutes.

We’re really excited to see what our customers are able to do with the new Android SDK. If you have any questions or feedback, we would love to hear from you at support@launchdarkly.com.

20 Sep

Launched: Prerequisites for Flag Dependencies

LaunchDarkly prereqheader

To perform smarter, conditional feature releases, our customers have asked for the ability to control feature dependencies in LaunchDarkly. In other words, they wanted to evaluate Flag B only if Flag A was “on” for a particular user.

For example, let’s say we have a feature flag that controls the visibility of a checkout flow with multiple steps. Within that flow, we have additional feature flags that control smaller elements, like a button and a modal. We want to make sure that the checkout flow is actually “on” for a user before we evaluate the flags for buttons and modals.

To provide this functionality, we have launched Prerequisites (beta), which lets you add a list of flags and their expected values as prerequisites to enable a feature.

Prerequisite Example

Let’s say we have two flags that control an API: api_reads and api_writes. In this case, it makes no sense to have write access to the API if you do not have read access. With prerequisites, you can make sure that api_reads is “on” with the user receiving true before api_writes is evaluated for that user.

You can manage your prerequisites in the feature flag’s Targeting tab:

LaunchDarkly Feature Flag / Toggle Dependencies - Prerequisites

You can add as many prerequisites as you want to a feature flag. We have checks built in to ensure that there are no circular dependencies and that deleted flags are automatically removed as dependencies.

Example Use Case

Mutually exclusive experiments

Let’s say we want to test whether the size or color of a button affects user engagement, but we want to run these two experiments at the same time.  Prerequisites gives you the ability to compartmentalize experimentation , allowing you to run exclusive experiments without hardcoding the logic into your codebase.  In this case, we want to ensure that users who receive the button size experiment do not receive the color experiment.

First, we have a feature flag that shows a red button to 50% of users:

LaunchDarkly Feature Flag Rollout

Second, we have a feature flag that shows a big button to all users who are receiving false for the ‘Red Button’ flag:

LaunchDarkly Feature Flag Rollout - Prerequisite flag dependency

In other words, all users who receive true for the Red Button flag will receive false for the Big Button flag.   This means that no user will get Red and Big for their button style.

Here is some example code (Java):

However, what if you now want to test making the button both Red and Big ?  You can do that with LaunchDarkly by simply changing the prerequisite value to true:

LaunchDarkly Feature Flag / Toggle Prerequisites - Inclusive Experiment

No code changes are needed. The beauty of this example is that your experiments are completely decoupled from your codebase.

There are many exciting ways to use prerequisites, especially when you take full advantage of our multivariate feature flags and custom rules.  If you have any questions or feedback, please send them to support@launchdarkly.com and we’ll be happy to help!

31 Aug

Secrets of Netflix’s Engineering Culture

Netflix is not just known for the cultural phenomena of “Netflix and chill”, but for its legendary engineering team that releases hundreds of times a day in a data-driven culture. Netflix is the undisputed winner in the video wars, having driven Blockbuster into the “return” bin of history. Netflix won by iterating quickly and innovating with numerous micro-deployments. Could what worked for Netflix work for you?

Netflix had a virtuous cycle of product innovation. Every change made in the product is with the goal of getting new users to become subscribers. Netflix has a constant flow of new users every month, so they always have new users to test on. Also, they have a vast store of past data to optimize on. Did someone who liked “Princess Bride” also like “Monty Python and the Holy Grail”? When is the right time to prompt for a subscription? Interesting tests that Netflix can run include whether TV ads drive Netflix signups, or whether requiring Facebook to create an account drives enough social activity to counteract the drop in subscriptions from people who don’t have Facebook. If a change increased new user subscriptions, it went into the product. If it didn’t increase new user subscriptions, it didn’t make it in – hypothesis driven development.

However, what if you’re not Netflix? What if you’re a steady SaaS business with 1,000 business customers, on boarding 30 new customers a month? This is a healthy business, doubling in size annually. However what if you wanted to test whether you get more subscriptions with a one step or two step process to add a credit card. With a sample set of 30 a month & 90% current success rate, it will take you three months to determine success. Not everything can be tested at small scale. Tomasz Tunguz talks more about the perils of testing early here.

The other “gotcha” to watch out for with Netflix style development is obsessive focus on one metric can degrade other metrics. For example, focusing on optimizing new user signup might mean degrading experience for old users. Let’s say that 10,000 customers could be served with “good” speed, or 2,000 with “superfast” speed and 8,000 with “not good speed”. Or 1,000 with lightning fast and 9,000 with terrible speed. You might make the 1,000 new customers very happy, but piss off the 9,000 existing customers and have them quit. A good counterweight is to always have a contra-metric to keep an eye on. It’s okay if it dips slightly if the main metric rises. However, if the other metric tanks, re-consider whether the overall gains are worth it.

So what lessons can you take from Netflix to help your own business?

One, have a clear idea of why you’re making changes, even if it’s not something that you can a/b test. Is it to increase stability in your system? Make it quicker for someone to onboard? Know what your success criteria are, even if there’s not a statistically significant “winner”.

Two, break down projects into easily quantifiable chunks of value. Velocity can be as important (if not more important) than always being right. For example if you try 20 small changes, and half are right, you’ll end up 50% better. If you try one big change, and it’s not accretive, you’ll end up with a zero percent gain. Or, as Adrian Cockcroft, Netflix Architect says “If you’re doing quarterly releases and your competitor is doing daily releases you will fall so far behind”.

Three, don’t underestimate the importance of your own domain expertise. If you’re constantly testing ideas, even without having enough data, you’re quicker to get into the right path. Let your competitors copy your past mistakes, while you move forward. As Kris Gale, co-founder and CTO of Clover Health said, “You will always make better decisions with more information, and you will always have more information in the future.” But the way to get more information is to iterate.

LAUNCHDARKLY HELPS YOU BUILD BETTER SOFTWARE FASTER BY HELPING MANAGE FEATURE FLAGS AT SCALE. START YOUR FREE TRIAL NOW.

 

29 Aug

Guide to Feature Flagging Best Practices

While there are many companies who practice feature flagging as a way to extend continuous delivery and release faster, there are just as many companies who are just starting out with the practice.  And until now, there hasn’t been a great resource for the feature flagging beginner.  Feature flagging as a concept is super straightforward, but must be implemented with diligence.  Haphazard feature flags can devastate a company, whereas well-managed flags can prevent disaster and even make your company more competitive.  


LaunchDarkly’s guide to feature flagging best practices addresses these deficiencies and provides a roadmap for better feature flag management.  While many aspects of feature flagging must be personalized to meet a particular company’s needs, the guide acquaints newcomers with how powerful feature flags can be and what they need to watch out for.  It also relays some pro tips for those who have been feature flagging for a while.  

LAUNCHDARKLY HELPS YOU BUILD BETTER SOFTWARE FASTER BY HELPING MANAGE FEATURE FLAGS AT SCALE. START YOUR FREE TRIAL NOW.

26 Aug

3 Ways to Avoid Technical Debt when Feature Flagging

Feature flags are a valuable technique of separating out release (deployment) from visibility. Feature flags allow a software organization to turn features on and off at a high level, as well as segment out their base to allow different users different levels of access. However, feature flags have an (ill-deserved) reputation of “Technical Debt”. Used incorrectly, feature flags can accumulate, add complexity, and even break your system. Used correctly, feature flags can help you move faster. Here’s three easy ways you can avoid technical debt when using feature flags.

  1. Create a central repository for feature flags

Using config files for feature flags is “the junk drawer” of technical debt. If you have seven config files with different flags for different parts of the system, it’s hard to know what flags exist, or how they interact. Have one place where you manage all of your feature flags.

  1. Avoid ambiguously named flags

Give your flags easy to understand, intuitive names. Assume that someone other than you and your flag could potentially be using this flag days, months, and years into the future. Don’t have a name that could cause someone to turn it on when they mean off, or vice versa. For example “FilterUser”, when it’s off – does this mean users are filtered? or not?

  1. Have a plan for flag removal

Some flags are meant for permanent control, for example for an entitlements system. Other flags are temporary, meant for the purpose of a release only. If a flag can be removed (because it’s serving 100% or 0% of traffic), it should be removed, as quickly as possible. To enforce this rigor, when you write the flag, also write the pull request to remove it. That way, when it’s time to remove the flag, it’s a two second task.

02 Aug

Feature Flag-Driven Releases

Feature flag strategy meeting

Using feature flags to incorporate a release strategy into your development process

 

The Old Way

The “old way” of software releases is characterized by an explicit waterfall hand-off between teams – from Product (functional requirements) to Engineering (build and deploy). This old way did not explicitly promote release planning in the development process. The full release burden was shifted from one team to another without plans for a feedback loop or integrated release controls.  Hence, it was difficult for teams to continuously deliver software, gather feedback metrics, and take full control over software rollouts and rollbacks.

With the rise of continuous delivery, teams are integrating feature release and rollout controls into the product development process.  This is ushering in a new era of DevOps where teams collaborate on release strategies during the initial design phase in order to manage a release throughout the development cycle, from local, QA, staging, and to production.

How will the feature be released?  Who will be getting this feature first?  Will it be gradually rolled out? Who will alpha/beta test it?  What if something doesn’t go right?  All of these considerations (and more) are typically not discussed in initial planning meetings. By codifying a release strategy from the start, you can ensure that your software release matriculates smoothly from build to release to sunset.

Release Strategy

Release strategy is a DevOps concept where teams integrate feature release planning into the development process.  Instead of pushing a new feature to production and being done with it, developers integrate feature flags into the development lifecycle to control their releases.  Broadly speaking, feature flagging is a way to control the visibility and on/off state of a particular feature by wrapping the code in a conditional.  The process of flagging encourages developers to plan for the initial feature rollout, feature improvements based on user feedback, and overall feature adoption.  It basically compels teams to incorporate a release strategy into the development process.

Josh Chu, Director of Engineering at Upserve, explains how his team incorporates release strategy:

“A lot of times people would say ‘let’s roll this out’ and not think about how to actually get adoption. The fact that you have a feature flag story raises visibility. Engineers start thinking about how their feature is going to get rolled out rather than just ‘push it to production, it’s done’. The product team is encouraged to take a more hands-on approach to pre-release feedback, which directly feeds into obtaining post-rollout traction.”

 

LaunchDarkly Rollout and Release Strategy Feature Flags and Feature Toggles

Strategic Rollouts Using Feature Flags

In this section, we illustrate an example of how a release strategy can be incorporated into a traditional design, build, test, and release process.

Stage 1 – Feature Design

  • Design the feature’s functionality, examine the target audience and use case, and develop a timeline for implementation.

Stage 2 – Release Strategy

  • Collaborate on rollout and release strategy.  Should the feature flag be a front-end flag, back-end flag, or both? (Front-end flags are mainly used to control UI visibility, while back-end flags can control APIs, configurations, and even routing).  What should be behind the flag?  Is this a permanent or temporary flag? (ex. permanent = ‘maintenance mode’, temporary = ‘new signup form’) Who has rights to change the flag?  Is the flag intended to control a percentage rollout? How will we incorporate user feedback? How will we measure adoption and traction?

Stage 3 – Build

  • Develop and integrate, using the feature flag to manage the feature’s progression through multiple development environments.

Stage 4 – Test

  • Test the feature in QA and Staging, using the feature flag to control rollout and user targeting.

Stage 5 – Release

  • Deploy the feature as ‘off’ in production and then implement your release and rollout strategy.  This could be an incremental percentage rollout, individual user targeting, or targeting groups of users.

LaunchDarkly Rollout and Release Strategy Using a Feedback Loop Feature Flags and Feature Toggles

Feedback Loop

By adopting a release strategy, Engineering, Product, and Design teams can continuously collaborate on release and rollout plans, assessing user and performance feedback along the way.  Bryan Jowers, Product Manager at AppDirect, comments on the benefits of controlled rollouts, “It allows us to bring product to market faster, test, get data, and iterate… Engineering, Product, and leadership are all looking to deliver product with low risk… and we do that with tightly controlled rollouts.”

Instead of pushing a future to production and being done with it, teams should be designing release strategies that incorporate targeted/incremental rollouts with the intention of iterating based on feedback.  This creates a continuous feedback loop because teams can synthesize performance metrics and transform those metrics into better, faster iterations.

Take-Aways

Release strategy incorporates release and rollout planning into the development process.  It forces teams to plan for feature rollouts and develop methods for aggregating user feedback, analyzing metrics, and assessing traction.  One of the proven ways to do this, as used by teams at Upserve and AppDirect, is to use feature flags to launch, control, and measure features from development to release.

 

LAUNCHDARKLY HELPS YOU BUILD BETTER SOFTWARE FASTER BY HELPING MANAGE FEATURE FLAGS AT SCALE. START YOUR FREE TRIAL NOW.