Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Where to Put Your Feature Flag?

DZone's Guide to

Where to Put Your Feature Flag?

Learn how to use feature flags in different types of development - like microservices, mobile apps, and web UI - for continuous delivery pipelines.

· DevOps Zone ·
Free Resource

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

Feature flags are a necessary part of your Continuous Delivery ("CD") pipeline. In fact, as your team grows, you can't do CD without feature flags. They give teams the ability to merge code directly onto master, release it to production dark, and then turn on access to customers when you are ready.

When talking about feature flags, a key question teams struggle with is this:

"What is the right layer of stack to put the flag in?"

For instance, if there is a new widget in the UI, should the flag live in the UI or in the backend? What if there is a new search or recommendation algorithm being released?

A handy rule to follow here is the "highest common access point" rule.

Say, a user can interact with a feature through the web UI, mobile app, or through a REST API. These are the three entry points to our stack. If we want to put this feature behind a flag, here are some scenarios and guidance on how to apply the rule.

When to Put the Flag in a Backend Microservice

If there is more than one entry point through which the feature can be accessed by the customer, then the flag should be placed in the highest level at which these two entry points converge. An example is LinkedIn testing a new algorithm to recommend other professionals to connect with aka "People You May Know." This feature is accessible via the web and mobile app. A LinkedIn user should see the same recommendations irrespective of web or mobile. The highest common access point for web and mobile endpoints is the microservice which is serving those recommendations. Thus, the flag should be placed in the microservice.

A significant benefit of this approach is that if in an emergency a flag has to be turned off (aka "killed"), the feature will be removed from all user experiences at the same time.

The same approach applies if the recommendations microservice is also available via an API.

When to Put the Flag in the Web UI

If on the other hand, a feature is only accessible in the web UI, then it is best to put the flag in the Javascript layer. This way if the feature is killed i.e. made inaccessible in the UI, it will no longer be accessible in the backend.

When to Put the Flag in Both the Web UI and Mobile App

Some organizations keep their web and mobile UIs completely separate, only sharing a database. The request path for a request originating from mobile and web hits different microservices on the way to the database. In that case, the highest common access point is the database which cannot be flagged. In such cases, there is no common access point, so the flag can be repeated both in the web and mobile UI.

Warning Signs

If two different flags are used in the web UI and mobile app to control the same feature, it can lead to a whole lot of pain. For instance, an engineer can ramp the web flag but forget to ramp the mobile flag. A user switching between web and mobile will have a broken experience.

Takeaways

When thinking through the problem of where to put a feature flag, use the "highest common access point" rule. It enables you to control your users' experience across the many endpoints through which they use your product.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

Topics:
devops ,feature flags ,continuous delivery

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}