Feature Flags: 3 Use Cases for your Development Cycle

Feature flags allow you to slowly rollout your feature gradually rather than doing a risky big bang launch and are extremely helpful when used in a continuous integration and continuous delivery environment.

However, when integrating feature flags into your development cycle it can be difficult to know where to start.

I’m Asa, Optimizely’s Developer Advocate. In part 1 of this blog series, I’ll cover 3 feature flag wins in development processes to help understand how you can integrate feature flagging into your process.

1. End Merge Conflicts

The Problem: Merge conflicts

Early in my development career, I would get so excited and focused on building a big new feature that I would forget about the consequences of trying to merge a big pull request in later.

I would pile change upon change in my asa/<new_awesome_feature> feature branch until I was done, but in my excitement to merge, I would get merge conflicts:

This is because in the time that I spent trying to build my feature, the codebase had changed as a result of my coworkers landing their changes in the same area of code as my new feature.

Ok Solution: Rebase often

The first solution you learn to deal with this problem of a long-lived feature branch is to frequently rebase onto your team’s latest changes. A better solution is to use a feature flag.

Better Solution: Continuous integration with feature flags

A better solution is feature flags. With feature flags, you can make a natural sandbox around areas of the codebase where you’re working. If you’re working on a new dashboard, you can start with a simple boolean wrapper:

By merging and deploying the feature flag first before you begin working on your feature, you clearly indicate to your coworkers where new dashboard code will be and naturally avoid code conflicts when merging.

You can also merge code before the feature is completely finished because you’ve hidden the functionality from users.

With this setup, you have short-lived incremental feature-branches landing more quickly and continuously with a much less chance of running into the headache of merge conflicts.

2. Iterate and Prototype exploratory code

The Problem: Production requires close to perfect code

Your company wants to innovate and you have a lot of crazy ideas, but you’re not sure if they are going to work or if they are possible in a production environment.

For example, you’re not sure if the API you are building will be performant enough on production data for it to be truly use-able.

Ok Solution: Find expertise

One solution is to do a lot of planning or find expertise or experience in others that may help guide you to the right answer. Maybe there’s an API expert at your company you can talk to.

However, with truly innovative ideas, no one will have the expertise to guide the right answers and may only have advice. Another solution is to use feature flags to prototype in production.

Better Solution: Prototype in production with feature flags

By using feature flags, you can deploy code to production that is not shown to your users or customers. This allows you to prototype different solutions in a real-world environment, proving or disproving what is technically possible without having to rely on knowing all information in advance.

Since the prototype is behind a feature flag, you can scrap the idea early if it is not technically feasible and the feature flag provides an easy marker for code cleanup of prototype changes.

3. Understand and predict scale issues

The Problem: Improving performance is hard

Performance and scale issues are challenging. Unlike other software problems, they are hard to predict and hard to simulate.

Often times, you only find out that your feature has a scale problem when it’s too late. You have too many users and your feature is starting to fail, your performance dashboards are showing ugly spikes in delays, error rates, and response times.

Ok Solution: Automated performance tests

One solution is to try and build performance or benchmarking tests. However, these test suites are complicated to get right because they require a very controlled environment in order to be able to accurately compare times. Furthermore, these tests often don’t actually reflect real-world experience or usage.

Another option is to use feature flags.

Better Solution: Real-world performance testing with feature flags

By instrumenting your feature with a feature flag, you can roll out your feature to a small percentage of your traffic and measure how your feature is scaling with a given set of traffic.

Having the feature flag allows you to be more mathematical in your predictions of whether a feature will scale while also using real world traffic in production for measurement.

Let us know what you think!

Hope these 3 wins helped show you how to integrate feature flags into your development processes.

If you enjoyed this post, keep your eyes out for the next part in this blog series on feature flag use cases and sign up for Optimizely Rollouts which is a free product that allows you to create and manage an unlimited number of feature flags!