Deep dive into Feature Flags, it’s features and implementation using LaunchDarkly in Java

In this post, we take a look at feature flags, its salient features and its implementation using LaunchDarkly in Java.

Introduction — Why do we need Feature Flags?

In enterprise-level development spread across projects, teams, and zones we are presented with the dilemma and have experienced the problems like

• Picking the right moment to release a new feature even though these features are ready in previous PI’s (Program Increment).
• When will deploy the new version of any service/ feature has the least impact on our users?
• How do we minimize the downtime and the time users are not able to access an application?
• What if we want to publish a feature at a different time than the new version is released?
• What if our feature depends on an API of an external system that is not ready yet or fully?
• What if we want to publish a feature to only a certain (set of) user(s)?
• What if we want to enable a feature across multiple microservices at the same time?
• How to deliver features selectively based on geographic locations, maybe one feature is not needed in one geographical location but needed in other locations?
• How to develop and deploy the features independent of the other team members as they continue their ongoing work on their related areas of the codebase to limit the risk to a small part, limited to our feature and prevent destabilizing the overall functionality?

There are various strategies to solve the questions raised above. One of the effective way to tackle it -

• Introduce feature toggles to toggle certain features based on various parameters like Users, IP Addresses, etc., and thus control the lifecycle of the feature, its accessibility, and usage.

Feature Flags

• It is a software development best practice of gating functionality.
• Functionality can be turned on/off via the feature flags, separate from deployment. It helps to manage the entire life-cycle of a feature, where a feature is an increment in program functionality.
• It is a method by which developers wrap a new feature in an if/else statement to gain control over its release. By wrapping a feature with a flag it’s possible to isolate its effect on the system and to turn that flag on/off independent of deployment.
• It is a core component of continuous delivery that empowers software organizations to release quickly and reliably. It helps support the branching strategy i.e help our project to adopt trunk-based development. It can enable us to control the order of release for various multiple interdependent services.
• Utilizing feature toggles, we can enable a feature after all nodes have upgraded to the new version, thus keeping the application reliable. Feature toggles can be set up for a certain set of users, thus enabling different functionality for different users. Feature toggles can enable/disable context-based features.
• Feature toggles can act as ‘manual circuit breakers’ when we need to disable certain features on runtime.

Salient Features

• Decoupling: This allows us to decouple feature roll-out from code deployment that gives unprecedented control to us, of who sees what, when, and independent of release.
• Canary Launches: It supports canary launches. We introduce the code base gradually to our user base. A small set of users sees the features. If there is an issue, we can find out with only a fraction of the user base seeing it. If everything goes well, we introduce new functionality to more and more users.
• Production Testing: It de-risks deploying functionality whose production behavior is unknown to us.
• Environment-specific configuration: We could take advantage of feature flags to toggle the right setup in the right environment.

Use Case 1: New features release can be controlled by flags

Use Case 2: Features available only to a certain set of users.

Implementation using LaunchDarkly

• For enterprise-grade feature flag platforms built specifically for development teams, which wraps the features in conditionals for full control over that feature’s visibility, which manages all the complexities, workflow, compliance, and control the life-cycle of the feature flags, LaunchDarkly provides such a platform.
• It provides continuous delivery and feature flags as a service platform. It integrates into a company’s current development cycle. It allows companies to continuously deliver and deploy software to their users in a faster, more reliable way.
• It wraps the features in LaunchDarkly flags, which allows it to have full control over who sees the feature (users or user groups). It helps companies perform gradual feature rollouts, disable buggy features without re-deploying, and reduce development costs with a more streamlined development cycle.

Salient Features: LaunchDarkly

• Early Access: Allows to run beta programs on our live application by explicitly including the people we want to see a new feature.
• Kill Switch: Quickly turn it off if our proposed new feature is performing poorly to greatly reduce the impact.
• Increments Roll Outs: This allows us to do phased rollouts to percentages of our users to verify there are no scalability issues.
• Blocks Users: Allowing us to enable a feature flag by which we can enable a specific user or user group to access some element of our site. There is also the capability to protect features from users by excluding them from ever seeing them.

QuickStart Guide:

• Create LaunchDarkly Account.
• Create your first feature flag — In my demo code, I have set my feature flag name as testing-123
• Set up the application — Select the language as Java and environment as production.
• Create a new maven/gradle project and add the “launchdarkly-java-server-SDK” Launchdarkly dependency.
• Note down your SDK key.
• Launch Darkly default provides us with two environments.
• Both the environments (Test and Production) have their own set of SDK-key, which is used to connect the LaunchDarkly SDK to a specific environment.
• Each feature flag that we create has its own set of targeting rules for each environment.
• This means that we can change our flag rollout rules in a development or staging environment for QA testing before rolling out to production.
• Follow the quick start guide and do as following:

• Every user has a unique identifier key. For example, User “Bob Loblaw” as shown in the example, has his unique identifier key as “UNIQUE IDENTIFIER”
• Build your application code and then start the application. The LaunchDarkly dashboard should show the message.

• As of now, the flag is disabled. Start the application.
• The console should print the following message: “Not showing your feature”.
• This is your old application code or feature.
• Visit your dashboard. Enable the flag after selecting the flag. Put the suitable comment and production(if production enabled) or testing(if testing enabled).
• Start the application again.
• The console should print the following message: “Showing your feature”
• This is your new application code or feature.

The thing is that we don’t even have to change the code to enable our feature. Just enable the flag and our new feature is deployed, if any problem occurs, just disable the flag and your old application code will be implemented.

Guide: Adding a new User

• Creating a new user is very straightforward. Following snippet shows:

• A new user (Henry Shaw) has been added with a unique user identifier key: “henry@example.com”
• The new user is associated with the flag “testing-123” (feature flag key for the flag)

• Start the application and refresh the user’s dashboard.
• The new user “Henry Shaw” is added and associated with the feature flag: “testing-123”.

Guide: Targeting users with Existing Flags

• Four users have been added.
• Bob Loblaw with key as “UNIQUE IDENTIFIER”, Bob Loblaw with key as “bob@example.com”
• Sam Smith with key as “Sam@example.com”, Henry Shaw with key as “henry@example.com”
• A new feature flag has been created. Name: “experiment” and the feature flag key: “experiment”
• Click on the feature flag you want to target the users with. We select the “experiment” feature flag.

Under the target individual users:

• In true subsection: Select the users for which feature flag should be ENABLED
• In false subsection: Select the users for which feature flag should be DISABLED
• For Henry Shaw and Sam Smith: feature flag ENABLED
• For both Bob Loblaw (they are different users with unique identifiers): feature flag DISABLED

• Save it — Put the suitable comment and production(if production enabled) or testing(if testing enabled).
• Code snippet for demonstration — All the four unique users are associated with the feature flag: “experiment”

• Start the application. Following should be the output in the console

• As we can see, the feature flag is enabled for SAM and HENRY users and disabled for BOB users.
• We can configure the user targeting for a particular feature flag.
• We can add or remove the user for a particular feature flag as per requirements.
• We can target the users in segments
• We can target users based on their attributes.
• We can schedule the user’s removal based on certain criteria.