DEV Community: Flagship.io

Need an honest review of our Free Trial Product Tour

Louis de Chateauvieux — Mon, 14 Feb 2022 09:50:10 +0000

Hi everyone!
I'm Louis, Product Marketing Manager at Flagship.io, our feature management platform.
I'm currently working on redesigning the product tour and since our solution is meant to be used by you guys, I'd like to know if you can sign up at https://www.flagship.io/sign-up/, then take the product tour and finally share your honest feedback on this survey?
While you are there, please feel free to try the platform, I am also collecting feedback about it.
Thank you very much, it would help me a lot.

The Many Uses of Feature Flags to Control Your Releases

Anthony Brebion — Wed, 08 Sep 2021 12:15:09 +0000

The use of feature flags has evolved and expanded as teams now recognize the value they can bring to their releases.

First, let's start with a simple definition of feature flags. A feature flag is a software development technique that lets you turn functionalities on and off to test new features in production without changing code.

This is a technique that can be employed across a wide range of use-cases, from the most simple to more advanced uses as various teams such as engineering and production teams across organizations have begun to recognize the benefits of feature flags in their software release strategy.

In this article, we will explore these different uses so you can see first-hand exactly what feature flags can do across different contexts depending on your pain points and objectives.

Many of the use-cases outlined below revolve around one main idea: risk mitigation. There may be a bug in production and you want to turn it off without delaying the release or you have second-thoughts about a feature and you're not ready for all your users to see it. So you'd rather test this feature on a subset of users.

Feature flags also increase productivity and speed of teams. You're no longer waiting to merge your code if other changes are incomplete; you just put it behind a flag until it's ready. With this, you get more predictability to your releases. There's no need to delay your release cycle for any last-minute bugs detected.

Therefore, we will see how the use-cases outlined below bring these benefits to your team.

Prepare for launch
- Hassle-free deployments: release anytime
- Controlling rollouts: progressive delivery
Time your launch
- Running experiments and A/B testing
- Continuous delivery
- User targeting
- Giving early access
- Power to the users: beta testing
- Dogfooding
- No trespassing allowed: blocking users
- Managing entitlements
Other scenarios
- By pass app store validation
- Kill Switch: turning off features
- Sunsetting features
- Managing migrations

Prepare for launch

Hassle-free deployments: release anytime

Feature flags allow you to deploy whenever you and your team sees fit. You no longer need to delay your releases. Any changes to a feature that are not yet ready can be toggled off with a switch.

What feature flags do in this scenario is separate code deployment from release. This is done through a release toggle, which allows specific parts of a feature to be activated or deactivated so any unfinished will remain invisible to users until they are ready to be released.

Why is the distinction between deployment and release significant? To answer this question, it is worth noting the difference between the two terms:

Deployment is the process of putting code in its final destination on a server or any other place in your infrastructure where your code will run.
Release is exposing your code to your end-users and so it is the moment when they get access to your new features.

This difference is why we talk about decoupling deployment from release because once you do that, you can push code anywhere, anytime, without impacting your users. Then, you can release gradually and selectively whenever you're ready through progressive and controlled rollouts as we will see below.

Controlling rollouts: progressive delivery

With feature flags, you are in complete control. This means once you have a feature ready for release, you can control which subset of users will see this feature through phased rollout of releases.

Such a practice is referred to as progressive rollout, which builds on continuous delivery to include the use of feature flags to gradually introduce features to your users.

Rather than releasing to all your users, which is often risky, you may want to release to just 5 or 10% of your users. These users should represent your overall users. Meanwhile, the team observes how these users respond to the new feature before rolling out to everyone else.

One progressive rollout technique is known as canary deployment. This is where you test how good your feature is on a small group of users and if there's any issue, you can immediately fix it before it's exposed to a larger number of users. This sort of gradual rollout helps mitigate the risk of a so-called big bang release. It also helps ease the pressure on your server in case it cannot handle the load.

You may also carry out what is known as 'ring deployments'. This technique is used to limit the impact on end-users by gradually rolling out new features to different groups. These groups are represented by an expanding series of rings, hence the name, where you start with a small group and keep expanding this group to eventually encompass all users.

In a ring deployment, you choose a group of users based on similar attributes and then make the features available to this group.

Rings and feature flags work together where feature flags can help you hide certain parts of your feature if they're not ready in any of the deployment rings.

The advantage of such controlled rollouts is the feedback you would generate from users, especially for releases you're less than confident about and so with the feedback received, you can improve your product accordingly.

Time your launch

We know at this point that feature flags give you the control to release at any time you deem suitable.

Feature flags, then, are important because you always decide the 'when'. As such, with feature flags, you can aim for a timed launch where you push your feature for people in your trusted circle, such as your QA team, to test in production. Afterwards, when it's time to launch, you simply turn on the feature for everyone else without any fuss with the added advantage that you're feeling much more confident when it comes to the actual release to everyone else.

This significantly reduces stress among your team because you've tested the feature before the official launch and you've made sure it's working as it should before going ahead with a wider release.

Running experiments and A/B testing

This is related to the previous point and another variation of controlled rollouts. Feature flags are great for running A/B tests where you can create feature variations and assign a subset of users to each variation and see which performs better.

This is a great use for product and marketing teams who can easily test new ideas and eliminate them if they don't fulfil the hypothesis defined upon creation of the test.

For example, feature flags would allow your product and marketing teams to send 50% of users to the new variation of a feature and the other 50% to the original one to compare performance according to the goals set and see which variation runs better.

Using feature flags to run A/B tests is particularly useful when a feature receives enough traffic to generate efficient results. So, as a cautionary note, keep in mind that not everything can be an A/B test when it comes to feature flags.

In this sense, you can look at feature flags like a light switch. You decide when you want to turn on the feature, when to turn it off and which users have access to it. This allows you to continuously test in production until you're satisfied with the end-result which you can then roll out to the rest of your users.

Continuous delivery

We've already seen that with feature flags, you can release at any time. Consequently, we can deduce that feature flags facilitate the process of continuous delivery.

Let's imagine you are all set to release but then one developer's changes have not yet been integrated into the main feature branch. Does this mean you need to wait especially when you know time is precious when it comes to releasing to impatient customers in this day and age?

Feature flags enable continuous delivery because as mentioned, feature flags decouple deployment from release so even unfinished features can be merged but can easily be hidden behind a flag so users don't see it while users get access to all the complete changes for testing.

User targeting

You don't just choose the when, you also choose to whom

Feature flags, as we've seen, gives you a lot of control over the release process by putting the power of when to release in your hands.

It's worth mentioning yet another form of power feature flags can give you, which is the ability to choose which users can access the feature. When you are testing in production, having the option to choose who you want to test on is extremely valuable depending on the kind of feedback you're seeking.

Giving early access

We've seen in canary deployment that sometimes the sample you pick can be completely random. Other times, however, you might decide to carefully handpick a select group of users to give them early access to your new feature.

Why is this important? Because these are the users that are considered to be 'early adopters'. They are users you trust and whose feedback is the top priority and who are most interested in this particular feature. These users are also the most forgiving should anything go wrong with the release.

With feature flags, you can release the feature to these early adopters who are more than willing to provide the kind of feedback you need to improve your product. This technique works well if you have a very risky release that you're hesitant to release to a wider audience.

Power to the users: beta testing

This is another side to early access where in this scenario users willingly opt-in to test out your new features before they are released to the rest of your users.

As a result, the customers who opt-in get to see and test the feature by turning it on in their accounts and should they wish to back out they can easily disable the feature, which makes these users more inclined to opt-in in the first place as it makes them feel more in control.

This is an important use-case because it shows your customers that you're really listening to their feedback by asking them to test your release. The users who opt-in are those who you're targeting with this feature so how they react to the feature will be of extreme use to you. Hence, you get to test out your new feature and you deliver value to your customers by responding to their feedback; it's a win-win situation!

Dogfooding

This term refers to eating your own dog food and is another way to test in production but internally.

Here, you basically release your new features or changes to people within your organization. This is a great way of testing especially when you're introducing new features or major changes that you're not fully confident in.

This way, you are taking less risks because it's only people within your organization who can see the releases as opposed to your actual, external users who may be more unforgiving in case things take a bad turn during a release.

No trespassing allowed: blocking users

Just as you can pick users who you want to access your feature, you can also block users from seeing it. For example, you can block certain users from a particular country or organization.

What feature flags would allow you to do is hide some features from these less forgiving users who might not give you the right sort of feedback while giving access to the relevant target consumers and who would be most impacted by the new feature.

Managing entitlements

With feature flags, you can manage which groups of users get access to different features. This is especially common in SaaS companies that offer various membership plans and so with entitlements, you can dictate which features each plan can access. This way, you would be offering different experiences to your users.

Let's take the example of Spotify. Spotify offers free and paid plans. With the free membership, you can stream music but with advertisements while with the premium membership, you can stream unlimited music with no ads. You also get unlimited skips and you can download music to listen to offline. There are also different levels of premium to choose from including student and family plans. Consequently, with each plan, you are entitled to different content and features.

With feature flags, you can wrap a flag around a feature and release it to a particular customer depending on their subscription plan. These types of flags are usually referred to as permission toggles. They also allow you to move features easily between the different plans i.e. paid and free versions, for example.

Managing entitlements is considered to be an advanced use case as it requires careful coordination across teams and involves working with multiple flags to control permissions for the features. The person who manages entitlements is usually on the product team so careful planning and monitoring of each change performed by which person is required. There should also be a seamless process in place to move users from one plan to another. Thus, this use case requires vigilant implementation.

Other scenarios

By pass app store validation

This is when we use A/B testing to test different experiences within mobile apps. Imagine you've just released a brand new app or introduced a new shiny update to your app.

How can you make sure your app or this update is running smoothly or that you haven't unintentionally introduced an update full of bugs that crashes on your users? Anything that goes wrong will involve a lengthy review process that will setback your entire release as you attempt to locate and resolve the issue.

You no longer need to wait for app store approval, which could take some time and the changes are released to all users instead of smaller segments.

Instead, with remote config implemented through feature flags, any changes can be made instantly and remotely and then released to a small subset of users to get feedback before releasing it to everyone else. Therefore, you can upgrade your app continuously in real-time based on feedback from your users without waiting on app store approval.

It's also a good way to personalize experiences for different types of users rather than creating a unified experience for all users depending on the demographics you set forth.

As a result, with feature flags, you can roll out different versions of your mobile app to monitor their impact by releasing different features to different groups of users. Afterwards, you can decide on what features will be incorporated in the final release of your app.

Using feature flags to test out your mobile app is an excellent way to generate buzz around your release by giving exclusive access to a select number of users.

Kill Switch: turning off features

Using feature flags will allow you to disable a feature if it's not working as it should. This is done by using a kill switch. Thus, whenever anything goes wrong in production, you can turn it off immediately while your team fixes the issue. This would prevent you from having to roll back the entire release so other changes can be deployed and released without worrying about delaying the whole release.

With a kill switch, you can switch off a specific, troublesome feature so you can decrease the number of users who can see it, including turning it off for all users if necessary until the issue is analyzed and resolved by your team. This way, you won't have to go through the entire code review process to locate the issue.

Kill switches therefore give you even more control over the release process. This not only empowers your team of developers but also marketing and production teams with no software development experience who can now easily test in production and kill a feature without having to rely on engineering support.

Sunsetting features

Feature flags can also enable the 'sunsetting' of features. For example, with time, you might see your usage of feature flags increasing and widening to encompass a number of features. However, this accumulation of features may eventually turn into a heavy debt.

This is why it is important to continuously keep track of which features you are using and which features have run their time and need to be retired from your system.

Sunsetting, then, enables you to kill off features that are no longer being used. Feature flags would give you an idea of the usage of certain features which would help you determine whether it's time to kill it off, lest you end up with the dreaded technical debt.

Removing unused features and clearing up old flags is the best way to keep such hidden costs in check. Thus, you should have a careful plan in mind to remove some flags once they have served their purpose or otherwise you end up with the aforementioned technical debt. This will require you to have an efficient feature flag management system in place to track down 'stale' flags.

Managing migrations

Feature flags can be used to safely and effectively migrate to a new database as business requirements change and evolve. What organizations would normally do before feature flags is a one-time migration then hope for the best as rollbacks are usually a painful process.

Obviously, the biggest risk that comes with switching databases is loss of data. Therefore, developers need a way to test that the data will remain intact during the migration process.

Enter feature flags. They allow you to facilitate migration and should something go wrong, you can disable the migration by simply toggling the flag off.

A percentage rollout can then be implemented using feature flags to validate the new database and any changes can be reversed by using feature flags as a kill switch.

Bottomline: Use feature flags, use them often but proceed with caution.

As we've seen so far, many of the use cases can be easily implemented. However, others will require the ability to make detailed, complex and context-specific decisions so a more advanced feature flagging system that enables such functionalities would be needed.

Regardless of what you decide to use feature flags for, one thing is clear: feature flags put you in the driver seat when it comes to releases. You are in complete control of the when and to whom you release. It also allows you to experiment to your heart's content but without the risks, especially when the release doesn't go as expected.

Working with feature flags also increases productivity among teams. As we've seen in the use-cases outlined above, it's not just developers who have complete control over and access to the release process but product and operations teams can release and roll back as needed.

You can use feature flags for many things across different contexts. Some may remain for a long period of time while others need to be extracted as soon as possible so as not to run into technical debt.

Thus, the general advice would be to use feature flags often but keep in mind that proactive flag management and implementation will be needed to maximize the benefits while minimizing the costs.

Don't just take our word for it. Start your feature flag journey and see for yourself what feature flags can do for you by signing up for a free trial at Flagship by AB Tasty.

How to Implement Feature Flags in a React JS App

Anthony Brebion — Mon, 05 Jul 2021 14:25:31 +0000

We discuss three ways to implement feature flags in your React apps, from the DIY approach to third party cloud based solutions through open source libraries.

Feature flags, or toggles, as described by Martin Fowler are a "powerful technique, allowing teams to modify system behavior without changing code." In other words, implementing feature flags as a set of patterns is a robust way to manage code complexity and deliver new features to users using CI/CD pipelines, reducing the time to value and decreasing the risk of deploying buggy, error-ridden code to production.

In summary, there are 4 different types of feature flags each with a different use case:

Release flags: These are temporary feature toggles, providing software developers with the ability to ship untested code as latent code that might never be turned on.
Experiment flags: These flags or toggles are utilized to perform A/B or multivariate testing. This is a highly dynamic flag and is only functional until statistically significant results are generated before the flag is removed.
Ops flags: These flags are usually short-lived and can be introduced when rolling out a new feature that has unclear performance implications, providing the operations team with the ability to disable this feature very quickly after the deployment has completed.
Permissioning flags: Permissioning flags are generally long-lived and are used to manage the features and groups of features that specific groups of users can access, such as premium features that paying customers can access.

Implementing feature flags inside React projects

Feature flags are an integral part of deploying software updates via CI/CD pipelines without disrupting existing functionality. There are several ways to implement feature flags in your React apps. Let's consider three of the most popular and common ways:

The do-it-yourself method where the developer writes the feature flag code from scratch.
The use of open-source libraries that are integrated into the React Single-Page Application (SPA).
Signing up with a cloud based solution.

Do it yourself: A simple and free solution

This method requires you to write code, switching feature flags on and off directly in JavaScript. By expanding on this method, let's consider a simple use case, including code samples from a feature flag React app project, before looking at the primary pros and cons of this method.

1. Setting up the React project

If you already have your React project set up, you can skip to the next section, "Adding new feature flags" otherwise, here is a step-by-step guide to setting up a new project.

The reactjs.org website notes that the create-react-app is the easiest way to develop a new single-page application with React.

Therefore, use the following code to create a new boilerplate app:

npx create-react-app my-app
cd my-app
npm start

2. Adding new feature flags

Now that we have the project created and an empty app template, let's look at how to add a feature flag in React.

Feature flags can be stored in different places such as a database server, inside local storage, or in a cookie. In this scenario, we will store them inside local storage.

The first step is to create a Reactjs feature flag file with the following format used to create new features. This will act as your config file that you'll update every time you want to turn on/off a specific feature.

[{
    name: 'banner',
    description: 'Banner shown on top of the page',
    active: false
}]

Each feature flag must have a unique name that we can later call or reference in React. A short description is also needed to describe the functionality it adds and an active flag to determine whether the toggle is on or off.

As seen from the code snippet for creating a banner flag, our flags are stored inside an array.

To store these flags in local storage, add the following function to your app.js file and call it at the top of your feature component file.

Note: This will create 3 new feature flags if there are no feature flags created in local storage (localStorage). You also need to use the JSON.stringify () method to convert the JavaScript objects into strings as localStorage can only handle strings.

const initFeatures = () => {
    if (!localStorage.getItem('flags')) {
        localStorage.setItem('flags', JSON.stringify([
            {name: 'banner', description: 'Banner shown on top of the page', active: false},
            {name: 'reporting-yn', description: 'Switch on reporting modules for premium clients', active: false},
            {name: 'info-message', description: 'Enhance info message with icon and link', active: true}
        ]));
    }
};

const App = () => {
    initFeatures();
    ...
}

3. Adding the feature component

In order to reference these feature flags in React and show/hide features based on these feature flags, you need to create a new React component . Define it in a file called feature.js and store it in your src folder.

This component accepts 2 props:

the flag name to check against,
the child content to be used (children prop).
The first step is to get the feature from localStorage and see if it is set to active or not. If the feature is active, we can render the feature; otherwise, we return null.

const Feature = ({name, children}) => {
    const features = JSON.parse(localStorage.getItem('flags'));
    const feature = features.find(feature => feature.name === name);

    if (feature && feature.active) {
        return children;
    }

    return null;
};

export default Feature;

This component will handle the toggling of feature flags on and off. Finally, you just import and render the component where you need.

import Feature from './feature';

const App = () => {
  initFeatures();
  return (
    <div className='App'>
      <Feature name='banner'>
        <Banner />
      </Feature>
    </div>
  );
};
export default App;

Pros

There are several advantages to using this method. The most obvious being the fact that when writing your own feature flag code, it is free, easily accessible, and highly available for small React feature toggle projects.

Cons

However, what happens when your application grows in scale, and you need to create and manage several different feature flags, both long- and short-lived?

This is where this method's disadvantages come to the fore. Succinctly stated, this method is difficult to scale where lots of flags are utilized. And as you can see from the code samples highlighted above, advanced features require more development work which can be challenging and complicated to maintain.

Feature flag open-source libraries for React

The second method is to use existing libraries that you can find on NPM or Github. A simple search for "feature flag" will lead you to multiple open-source libraries or packages. Here are a few examples of these packages:

Flagged, for instance, provides nice features such as:

Hooks API
High Order Component API
Render Props API
TypeScript Support
Zero Dependencies
Nested Flags

Pros

The advantages of using these open-source libraries are that they are freely available, easy to use, and quick to set up. As described above, all you need to do is consume the libraries into your application and then call the functions created in the library files, passing in variables as required and reading returned variables to understand the state of your feature flags.

Cons

However, as with everything, there are also disadvantages to using open-source feature flag libraries. The most prominent includes the fact that maintenance and evolution are not guaranteed, and the library's functional scope might not suit your app's specific requirements. In both cases, a fair amount of refactoring and new code development will have to take place to maintain the existing code and add the features specific to your application.

Feature flag management platforms

The third and last way to implement feature flags in a single-page application is using a dedicated feature flag management 3rd-party service that provides a React integration.

By way of expanding on this statement, let's look at a step-by-step guide on how to set up feature flags in Flagship.io with the React SDK. As an alternative, you can also directly call the Flagship Decision API (REST API), but for the sake of simplicity we'll use the dedicated SDK that provides additional capabilities out of the box (ex: bucketing). The platform also provides additional SDKs for JAVA, Python, PHP, .Net, Go, iOS, Android, Flutter...

As a cloud-based feature management service, using Flagship.io is a 2- step process. First, in your codebase, you wrap your features once with flags using methods and providers from the React SDK. Once this is done, you remotely configure your flags (values, segments…) from the Flagship.io dashboard.

1. Set up the React SDK in your SPA project and wrap features with flags

Let's use the same project that we created in the first method (Setting up the project) using our create-react-app boilerplate app.

Install the SDK using NPM or yarn.

npm install @flagship.io/react-sdk

Import the Flagship provider from the React SDK which makes Flagship features available to the rest of your app. You can wrap your app directly within the app.js file.

The envID and apiKey props are required. You access them from the Flagship UI under the "Settings" section. For more information on the different props available, please refer to the API references.

import React from "react";
import { FlagshipProvider } from "@flagship.io/react-sdk";

const App = () => (
  <>
    <FlagshipProvider
      envId="YOUR_ENV_ID"
      apiKey="YOUR_API_KEY"
      visitorData={{
        id: "YOUR_VISITOR_ID",
        context: {
          // some context
        },
        isAuthenticated: false,
      }}
      enableConsoleLogs={true}
    >
      {/* [...] */}
    </FlagshipProvider>
  </>
);

Then, from the React component you want to get access to your flags, import and use one of our React Hook. useFlagship hook is the most useful one from our React SDK. It gets modifications assigned to the current user as well as further functionalities, such as sending hit tracking, checking the SDK status…

import { useFlagship } from "@flagship.io/react-sdk";

export const MyReactComponent = () => {
const fsParams = {
  modifications: {
    requested: [
      {
        key: "btnColor", // btnColor is your flag identifier that should be declared in the Flagship UI
        defaultValue: "green",
        activate: false,
      },
    ],
  },
};

const {
  modifications: fsModifications,
  status: fsStatus,
  hit: fsHit,
} = useFlagship(fsParams);

return (
    <div
      style={{
        height: "200px",
        width: "200px",
        backgroundColor: modifications.backgroundColor,
      }}
    >
      {"I'm a square with color=" + modifications.backgroundColor}
    </div>
  );
}

2. Declare your flags in the Flagship UI and set up values

The first step is to sign up with Flagship.io and sign into your account.

You can refer to this short video that goes through all the process of a feature flag setup or read the detailed instructions below.

Creating your feature flag use case

To create a feature flag from the dashboard, apply the following steps:

Go to the Flagship dashboard.

Click the + button.
Choose an existing project or create a new one
Click the "Add a use case" button.
You are presented with a list of different templates or use cases (ex: progressive rollout, A/B test...)
Choose the "Feature toggling" template.

Entering the basic information

First, you need to enter the basic information of your feature flag use case:

The feature name: use the most representative name for your feature, because this is the one you'll need to remember in case you want to find it later.
The feature description: explain exactly what your feature deployment is about and what its purpose for your business is.
The primary/secondary metric to follow (optional) which will serve as a point of reference to analyze performance. For more information, refer to Configuring KPIs.

Defining flags

This is where you configure the flags and their values based on your different scenarios. Think of it as the config file mentioned in the first method, but that you manage remotely from the cloud. Important: flag names you specify here should match the ones used in your codebase ("btnColor" in your code example above).

Defining targeting

During this step, you can define which users will be assigned to your different flag values. This is a segmentation engine built into the platform that makes it easy to assign flags conditionally based on user traits (or attributes) that you have access to in your codebase. Refer to this article about feature flag targeting for more information. The 3 following options are available:

All Users if you want all your users to progressively see your feature.
Users by ID if you want only users with a specific ID to see your feature.
Key if you only want users matching this key value to see your feature.

Enabling your feature

Once you have configured your feature, it is OFF by default to allow you to check that it is correctly configured. Back to the dashboard, you can activate your feature ON when you are ready!

And that's it. Now, provided changes to your codebase have been deployed, you can activate/deactivate feature flags, remotely change their values and have your React App react instantly to these changes.

Last thoughts

This article describes three ways of implementing feature flags in a React SPA (single-page application):

the do-it-yourself method,
using open-source libraries,
signing up with a dedicated feature management platform.

While there are pros and cons to each approach, the third-party vendor option is probably the most efficient method for large teams with evolving use cases that don't want to deal with the challenges of an in-house system.