Feature toggle with strategy constraints enable a new set of working efficiently with feature toggles in a developer workflow. A typical use case for Strategy constraints is that you want a feature toggle enabled for everyone in QA but only for a limited set of users in production. So far there have been different workarounds to enable this; Some users have used custom strategies to control roll out in different environments. We have also seen a pattern of prefixing the name of the feature toggle with the name of the environment.

How to get started for a feature toggle?

1. Upgrade client SDK

The first thing you need to do is to make sure you have the correct client SDK. We have implemented support in the following clients, make sure you are using the correct version:

(we are working on adding support in Ruby and .Net client as well)

2. Configure client SDK

In order to start using environment constraints you will need to specify which environment your application is currently in as part of initialization of the unleash client. This is done by specifying the “environment”  configuration options. Remember to also set up an environment for local development. For further details, please go to our “Getting started” section.

Java:

UnleashConfig unleashConfig = UnleashConfig.builder()
.appName("my.java-app")
  .instanceId("your-instance-1")
  .environment(System.getenv("APP_ENV"))
  .unleashAPI("<API url>")
  .customHttpHeader("Authorization", "<client secret>")
  .build();

Unleash unleash = new DefaultUnleash(config);

Node.js

const unleash = require('unleash-client');
unleash.initialize({
  url: '<API url>',
  appName: 'my-node-name',
  instanceId: 'my-unique-instance-id',
  
environment: process.env.APP_ENV,
  customHeaders: {'Authorization': '<Client secret>'}
});

3. Start using it

When you create an activation strategy for your feature toggle, it will contain a section “Constraints”, as seen in the example below.

Feature toggle strategy constraint on flexibleRollout activation strategy

As shown in the figure you can define which environment this strategy applies to. If not all the strategy constraints are not met, this strategy will not be used. 

As you probably know you can define multiple activation strategies together to increase the exposure, and they are logically ORed together. By combining this with strategy constraints, you are now able to constrain a strategy configuration to only applied in certain cases, such as an environment. This enables you to configure different roll-out per environment. 

Feature toggle strategy constraint on different environments in your workflow

In the example above we combine “100% rollout in development” with “50% rollout in production” and no custom strategy is needed to solve this!

Constrain on other things?

Even though it is nice to be able to control different roll-out per environment, you might also want to constrain on other things as well. We call these custom context fields, and you can configure your instance with any context field that make sense for you.

Some example our customers use in production today:

  • country
  • tenantId (or customerId, companyId).

Combining this with environment and the flexible rollout make you in control of how you activate features in your context.

An example on what we can achieve with this:

environment IN "prod" AND country IN "Norway" AND rollout=50%

All this possible without any custom activation strategy.