Feature flags with LaunchDarkly

Decision

We use LaunchDarkly to release independently of deployments.

Problems

When writing code, for a long time new features are not releasable to users. At some point, they might be releasable to some users, but not all, e.g. only internally, or only to beta users that we talked to personally about the feature.

Context

Options

• Big-bang releases
• Different environments
• Self-build feature flag solution
• LaunchDarkly
• AWS Evidently

Reasoning

Why feature flags?

We need to be able to release independently to users, as we rely on user research and user testing to get feedback early.

If code can only be merged to the main branch once it is fully releasable, this causes merge conflicts which can be hard to resolve. It also isn't always feasible to create separate environments for each group of users, especially when rolling out features to users in production.

Feature flags are checked in the code and return different values depending on which user is currently using the application. The code can then decide based on the value whether a feature should be displayed/used or not. This decouples deployment from releases, as code that is hidden behind a feature flag can be deployed, but will never be executed until the flag is enabled.

Why LaunchDarkly?

AWS Evidently is still in its infancy and hard to introduce in the frontend. LaunchDarkly is one of the industry standards right after Optimizely, but significantly cheaper.

Consequences

We need to add feature flag capabilities to our frontends. We need to train everyone how to use LaunchDarkly.

Related

None