Release Toggles

As explained in the core concepts section, release toggle is a mechanism used to control features' visibility.

Let's see how to create your first awesome release toggle. Click on the Release Toggle section on the sidebar.

Enter the name of the feature; you notice that the key will be complete automatically. The key must be unique in the project, is the way Koople identify your release toggle. If the key already exists, the platform will throw an error message when trying to create it, and the key must be changed to complete the process. Optionally, you can add a description to your release toggle.

Try naming your release toggle with descriptive names. For instance "Social login button", the key will be automatically filled as "social-login-button". This naming will help you when coding, improving human readability.

When a release toggle is created, it is replicated in all the same project environments in a disabled state by default. Similarly, when we create a new environment, it will already have all the release toggles created in the same project's other environments.

Pay particular attention to the "Server Only" checkbox. The release toggles (and remote configurations) marked as Server Only will be evaluated only by the server SDKs, never by the client SDKs. The main reason is that, for example, you may want to provide confidential information (for example, some configuration keys). For this reason, we will prevent it from appearing outside of trusted environments such as a web browser.

Release toggles are short-lived features. We have set a maximum of 30 days (somewhat subjective but we have pulled high) to display an alert on the panel.

To disable the alert, it would be enough to mark the feature as Long-live (kill-switch is an example of a long-live feature).

Release toggles have three possible states:

1. Disabled: Default state on creating. That state means that the feature is disabled for all users.

2. Soft Released: The feature is enabled for certain users. We will go into detail below.

3. Released: The feature is enabled for all users.

Disable and Release states are quite easy to understand: visible or not visible; enabled or disabled. But, when we are developing new features, we want to access our new feature. Initially, maybe it's enough if only the developer has access. Still later, we need to give access to other team members like other developers, QAs or even business people.

The soft release has different ways to identify the users that will be able to access the feature. The most direct way is just setting the user identifier; that identifier is how your application identifies the user. For example, if the users are identified by the email just put the allowed users' email on the identities input.

The user identifier is whatever your application use to identify the users. It can be an internal id, an email address, a username...

Then in your SDK:

Javascript

import {PFClient} from "@pataflags/sdk-js";

const pfclient = PFClient.initialize('YOUR_API_KEY', {});

pfclient.onReady(() => {
    const user = { id: '[e-mail]' };

    const isEnabled = pfclient.isEnabled('social-login-button', user);
    if (isEnabled) {
        // Do something when the feature is enabled.
    } else {
        // Do something when the feature is not enabled.
    }
})

C#

var pfclient = PfClient.Initialize('YOUR_API_KEY');
​
var user = PfUser.Create('[e-mail]');
var isEnabled = pfclient.IsEnabled('social-media-button', user);
if (isEnabled) {
    // Do something when the feature is enabled.
} else {
    // Do something when the feature is not enabled.
}

Java

PFClient pfclient = PFClient.initialize('YOUR_API_KEY');

PFUser user = PFUser.create('[e-mail]');
Boolean isEnabled = pfclient.isEnabled('myAwesomeFeature', user);
if (isEnabled) {
    // Do something when the feature is enabled.
} else {
    // Do something when the feature is not enabled.
}

Learn more about how to get you API keys.

However, identifying users by identities may not be enough, especially when identifying user groups. For these cases, we will need to add identification rules. These rules are simple logic operators like exist, is one of, greater than, etc.

The complete list of operators:

• is one of

• is not one of

• exists

• doesn't exist

• contains

• does not contain

• <

• <=

• >

• >=

• is truthy

• is falsy

• user in target group

• user not in target group

Learn more about how to reuse rules using target groups.

It is possible to combine different rule with and/or operators.

Moreover, it's possible to enable the soft release for a specific percentage of users.

Identities, rules and percentages can be combined for creating powerful soft release toggles!

But take into account the following rules to fit your release toggle properly:

• Identities do not apply to rules or percentage, if a user identity match, the user will be able to access the feature 100%.

• If the soft release has rules, the percentage is applied over the users that match the rules.

• If the soft release doesn't have rules, the percentage is applied over all the user.

• Do not feed them after midnight! :)

Let's describe a use case with soft release:

• As a developer, I'm working on a new feature. I create a release toggle to keep it under control. I switch to soft release adding my identity to view the feature in my development environment.

• My new feature seems to work fine. It's time to deploy in the test environment. I create the Test environment and add the QA guys to the soft release only in the Test environment's release toggle.

• Meanwhile, the project is still safe to be deployed in production, and the feature is no visible for anyone. The feature is not blocking the continuous delivery.

• After some tests and minor fixes, we are ready to deploy to production.

• Switch to soft release the release toggle in the production environment. First, for the QAs and me, when tested, we can start releasing for a percentage of users.

• If we found some error, we have to switch to disabled the release toggle and the feature will not be available in production.

• Finally, when we are sure the feature is working fine, we can switch to release.

When a feature under a release toggle is totally released, removing the release toggle from your code is highly recommended. Please, keep your code clean!

Let's see how this works with the SDK

Javascript

import {PFClient} from "@pataflags/sdk-js";

const user = { id: '[e-mail]', country: 'gondor', age: 31 }
const pfclient = PFClient.initialize('YOUR_API_KEY', user);

pfclient.onReady(() => {
    const isEnabled = pfclient.isEnabled('social-login-button');
    if (isEnabled) {
        // Do something when the feature is enabled.
    } else {
        // Do something when the feature is not enabled.
    }
})

C#

var pfclient = PfClient.Initialize('YOUR_API_KEY');

var attributes = new[] { 
    new PfUserAttribute("country", 'gondor'), 
    new PfUserAttribute("age", 31)
};
var user = PfUser.Create('[e-mail]', attributes);

var isEnabled = pfclient.IsEnabled('social-media-button', user);
if (isEnabled) {
    // Do something when the feature is enabled.
} else {
    // Do something when the feature is not enabled.
}

Java

PFClient pfclient = PFClient.initialize('YOUR_API_KEY');

PFUser user = PFUser.create('[e-mail]')
                    .with("country", "gondor")
                    .with("age", 31);

Boolean isEnabled = pfclient.isEnabled('myAwesomeFeature', user);
if (isEnabled) {
    // Do something when the feature is enabled.
} else {
    // Do something when the feature is not enabled.
}

It's possible to check the state of all release toggles in a single view on the Overview page.