In most successful companies, products and their underlying infrastructure are constantly evolving to changing needs and growing demand.
Shipping new features, improvements, or other changes can require careful planning ahead of a release. While you can try to imagine and rule out different failure scenarios ahead of time, you never really know what’s going to happen until you ship.
Sure, you could set up shadow reads/writes or split production traffic to hit an isolated clone running the new code, but depending on your resource budget and current infrastructure, that effort might be hard to justify.
For new versions of an existing feature, you could also fall back to the old logic on failure or compare new output with existing results and log any deviations, as they occur.
In small, fast-moving teams, you want to roll out features at a faster pace, but you cannot afford to break the experience for higher-paying and enterprise customers. So what if you could gradually roll out new features across segments, starting with free users and moving up the subscription tiers in steps?
Feature flags are a tool used for toggling specific parts of your product on or off for a certain set of users without having to reboot or reconfigure services. With feature flags, you can distinguish between different segments (groups of users) and gradually enable a flag for a small and then growing percentage of users over time. If something goes wrong, you can simply disable the flag and users will work on the previous version.
This flow only works when you can switch between implementations without migrations. In case you’re releasing a big feature by migrating individual users, consider enrolling eligible accounts in the migration process incrementally. You should probably strive to limit large migrations to speed up the rollout process and reduce your team’s maintenance burden.
In case you’re switching between two implementations with identical interfaces, feature flags are a perfect match. Slowly increase the percentage of users exposed to the new implementation and optionally enable fallbacks to the previous version for all users. Once everyone is using the new code, you can slowly remove the fallbacks as long as the new implementation doesn’t cause any issues. Once nobody is using the fallback, you can completely drop the old code.
In the past, I’ve used LaunchDarkly to create and integrate feature flags into products I worked on. With LaunchDarkly, you can configure feature flags to target specific users in different segments (or a percentage thereof), without worrying about performance degradation, as flag rules are stored in memory and evaluated without a network roundtrip.
Properly planning feature rollouts removes a lot of stress factors from the team. If you have a clear plan and options to roll back to the previous experience if anything goes wrong, your coworkers and customers will thank you for it.