Lesson 2: Life cycle
This lesson covers the lifecycle of feature flags, from their creation to their eventual removal or archival. We'll explore how feature flags evolve alongside feature development, the differences in managing flags across backend, web, and mobile environments, and best practices for cleanup and reuse.
Feature flag evolution
During feature development, it's common to start with a single flag that controls all configuration for that feature. This flag can hide the feature until it's ready for release. Using the feature flag, you can remotely toggle the feature for yourself and selected colleagues during development. As development progresses, the flag evolves with the feature, and different properties may be added or removed. By the end, the flag might contain just a simple boolean 'enabled' property, or it might retain certain aspects that you want users to control through experimentation.
Example life cycle
To illustrate the life cycle of a feature flag, we will go step by step, from creation to removal, both in your experimentation platform and your app code.
-
Create a flag
- Create the flag in your experimentation platform
- Add the flag to the app code
- Test it with your team
-
Parameterize the user experience
- Add properties to the flag and connect them to the feature
- Set default values matching the current experience
- Run A/B tests to optimize property values
- Gradually roll out the winning variant
-
Update default values
- Update the app code with the new default values
- Release a new app version
- Wait for user adoption
-
Remove the flag
- Replace feature flag code with hard-coded values
- Remove the flag from the experimentation platform
In Confidence, create the flag in the Confidence app (step 1) and remove it from the Confidence app when cleaning up (step 4).
Post-experimentation: Flag retention
After completing an experiment and rolling out the winning variant, you have three options:
- Clean up the flag
- Retain the 'enabled' property as a safety switch for quick feature disabling
- Retain the full flag to enable future iteration
Consider these factors when deciding how long to keep a flag:
Code complexity and bundle size
Feature flags create conditional branches in your code ('if enabled'). Keeping these branches increases code complexity and bundle size.
While feature flags offer great flexibility, maintaining too many can lead to unsustainable complexity and increased bundle size, as we've learned at Spotify.
User experience after flag removal
For backend services, you control the code version in production. However, with mobile apps, you need to consider how removing a flag affects users on older app versions. You might want to maintain the flag until you achieve high adoption of the new app version, which can take several months for some apps.