Core Concepts
Last updated
Was this helpful?
Last updated
Was this helpful?
Feature flags (aka feature toggles, controlled rollouts, experiments) are a development technique that allows you to ship code and features before they are finished and allow teams to modify system behaviour without changing code.
Feature toggles fit well with the practice of Continuous Integration and Delivery (CI/CD) and with techniques like A/B testing, remote config and canary releases.
A release toggle enables the developers to quarantine off their unfinished feature from the rest of the codebase and turn on and off the feature in different environments for testing.
Release Toggles allow incomplete and un-tested codepaths to be shipped to production as latent.
Let's describe a typical release toggle scenario:
We are going to implement a new offers section on our site.
Create a new release toggle in Koople. By default, the feature is disabled on all the environments. Set it to enable on your development environment.
Now, you can start working on your feature, wrapping it in a conditional statement. Only show the new section if the flag is set to true.
You can deploy your code to other environments safely. The flag hides the new feature.
You can allow other members (developers, QAs, POs...) to see the feature by adding their identifiers to the release toggle.
When the new feature is ready to be released, enable the release toggle to all users.
Remote configurations are a development technique where the behaviour of features of an application can be changed remotely without publishing an application update.
Target groups allow you to segment your users into different groups based on common attributes. Target groups allow you to set different setting values for other users in your application, grouping your users based on a set of rules.
You can set inline rules or define a set of rules as a target group to reuse in different toggles.
These target groups can be used to identify the users who toggle apply.
A user is an identified unique individual evaluated in each project environment. Each time your application sends via SDK a new user with ID and attributes, it is created as a user in the Koople platform.
The people in your team (organization members or outsider collaborators) are allowed to manage the different Koople options. It's possible to control the member permission at three levels: organization, project and environment.
Learn more about managing .
Learn more about managing
Learn more about managing .
Learn more about how to get .
Learn more about managing .
The highest level in the Koople hierarchy. Organizations group projects and allow to invite members to work in. .
All projects must pertain to an organization. It represents your working project and allows you to create multiple environments inside. .
Represent your project environments and allow you to configure the toggle behaviours individually for each of them. .
