Feature flags and rollout

Feature flag separates code-laying from behavior-enabled behaviors, and allows you to limit risk, but creates a time-consuming complexity in the system. For each flag, specify the owner, audience, metrics, full-on or rollback plan, and the date of deletion from the code.

What are feature flags and why do they need them?

Definition

Feature flag is a mechanism that allows functionality in a product to be turned on and off without deploying new code, usually a flag that is stored in a config or in a separate service and controlled via a UI or API.

Benefits of using

Feature flags give flexibility: you include new functionality to a group of users, test hypotheses, roll back changes without urgent releases.

Example of application

You release a new partition in the app. After the deploitation, only the team sees it. You test on yourself, find bugs. Then you open up 5% of users, follow the metrics, make sure everything is stable. After that, the feature flag is removed, and the partition is available to everyone.

Classification and types of feature flags

Types of feature flags

Feature flags are divided into release (release toggles), experimental (experiment toggles), temporary (ops toggles) and long-term (permanent toggles). The releases are for controlling new releases; the experimental ones are for A/B tests; the operating ones are for switching quickly when problems are encountered; the long-term ones are for customizing the product.

Anti-patterns

A common mistake is forgotten flags. Old code with a bunch of feature flags makes it difficult to support a product; another anti-pattern is to mix business and technical featureflags when it is not clear who is running it or why.

Example

One team didn’t clean old flags in years, and the result was that they were bugged by a combination of incompatible logic, and the solution was to isolate the process of cleaning out the irrelevant flags and automate reporting on them.

How to build a rollout process with feature flags

The main stages of rollout

Step 1: Release on the narrowest segment (e.g., internal or beta) Stage 2: Gradual expansion (2-5-10% of users) Stage 3: Metrics analysis (errors, performance, business metrics) Step 4: Disconnection or rollback in case of negative change in indicators Stage 5: Complete rollout and removal of the feature flag

Processes and best practices

Every step requires a person to be responsible. Measure key metrics immediately after the feature is turned on. Keep a checklist of criteria when to move to the next stage. Prepare a rollback plan: how to quickly turn off the feature through the flag if something goes wrong.

Tools for feature flags and rollout

Popular services

1. LaunchDarkly is a market leader, SaaS, multifunctional, support for complex rollout scenarios and A/B testing.
2. Unleash – Open source, you can implement on-premise, flexible segment customization.
3. Split.io – focus on analytics and experimentation, API-first, support for flexible rollout strategies.

When to write, when to write, when to write.

Ready-made SaaS services – faster to enable, less support, understandable SLA and documentation. Open Source like Unleash – You need more resources to support, but usually cheaper on a larger scale, more control and customization. Built-in solution – suitable for starting in very simple projects and MVP, but quickly becomes a brake if you need rollout or features for different audience segments.

Example

With a 100k audience, users decided to move away from their solution on LaunchDarkly, resulting in faster rollout, fewer crashes, easier communication between product and development, but increased costs, so calculating the cost of service is a separate task.

Organization of work with feature flags: practice and antipatterns

Roles and responsibilities

Each feature flag must have an owner: someone who knows why the flag was added, who is responsible for rollout and removing the flag after the experiment or release is complete.

Documentation and inventory

If you do not keep a register of flags, bugs, difficulty in debag and technical debt begin. Approach: Any new feature is described in a single system or wiki, where the purpose, date of creation, owner, criterion of disappearance are explicitly stated.

Example of approach

The rule is that every flag lives for no more than N weeks. Before each retrospective, they go through the list of feature flags and close the irrelevant ones. Tool support is mandatory: ping bots, reports, reminders.

FAQ

1. How is feature flag different from configuring? Feature flag is faster, you can turn on/off the feature without release. There’s usually a UI to control, rollout to share users and other logic.

2. What metrics should I monitor when rollouting on a feature flag? Look at errors, kickbacks, average response time, user response, targeted business activities (e.g. conversions).

When to delete feature flag?** After full release and confirmation of stability, it’s not worth holding any longer because of the growing technical debt.

**4. Is it better to choose a SaaS or an Open Source solution? If you need a quick implementation and SLA, SaaS. If flexibility, control, budget is important, open source.

5. What are the most common mistakes you make when working with figflags? They don’t keep a register, forget to delete old flags, mix different types of flags without documentation.

**6 Can you rollout without the tools? At the start, yes, but as the product grows, it becomes dangerous and uncomfortable, and it’s better to implement specialized services right away.