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 toggle with the name of the environment.

How to get started?

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.

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

We have already upgraded the Unleash instance for our customers with strategy constraint support. Currently the new feature is only available via the “flexibleRollout” strategy, which is scheduled to replace all rollout* strategis in v4. 

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. 

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 cusomterId, 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!!