Core Concepts
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.
Learn more about feature flags
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:
- 1.We are going to implement a new offers section on our site.
- 2.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.
- 3.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. - 4.You can deploy your code to other environments safely. The flag hides the new feature.
- 5.You can allow other members (developers, QAs, POs...) to see the feature just adding their identifiers to the release toggle.
- 6.When the new feature is ready to be released enable the release toggle to all users.
Remote configurations is a development technique where the behaviour of features of an application can be changed remotely without having to publish an application update.
Target groups allow you to segment your users in different groups based on common attributes. Target groups allow you to set different setting values for different 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 whom toggles apply.
A user is an identified unique individual evaluated on each project environment. Each time your application sent via SDK a new user with id and attributes, it's created as a user in Koople platform.
The people in your team (organization members or outsider collaborators) that are allowed to manage the different Koople options. It's possible to manage the member permission at three levels: organization, project and environment.
The highest level in the Koople hierarchy. Organizations group projects and allow to invite members to work in. Learn more.
All project must pertain to an organization. Represents your working project and allow create multiple environments inside. Learn more.
Represent your project environments and allow you to configure the toggle behaviours individually for each of them. Learn more.
Last modified 2yr ago