DEV Community

Cover image for Using Feature Flags to decouple Deployments from Releases
Chris Joy
Chris Joy

Posted on

Using Feature Flags to decouple Deployments from Releases

In regular software development, new features and updates are released to everyone at once. But that can cause some issues, like introducing bugs that can mess up the user's experience. It can also be tough to test and make new features work perfectly before they go live.

Feature flags fix these problems! They let developers release new features to certain groups of users or gradually turn them on. This way, they can test and make features better before everyone gets them, making it less risky and smoother for everyone.

Traditional Deployment Strategies​

Deployments are super important in software development! They're all about moving code from one place to another, like from a testing area to the final product. Some ways people used to do deployments were through things like Git flow, which is a branching strategy.

Git Flow

Git flow is a cool way that developers can manage their code and deployments. It works like this: they create separate branches for different features they're working on, and then merge them into the "develop" branch. This branch has all the newest feature changes, and they can send it to a testing area (called "staging") to make sure everything works right.

Git Flow

Sometimes, there are bugs that need to be fixed right away without having to wait for the next update. That's where hotfix branches come in! They're like a shortcut that helps developers fix issues quickly and without having to wait for the next big update.

Once everything is good to go, the "release" branch has the most stable version of the app, which is what users will see. This way, everyone can be sure they're using a version that works well.

Using Git flow for deployments is better than just sending things straight to the finished product. But there are still some issues. Fixing things with hotfixes can take time, and it's important to make sure bad code doesn't get into the release branch and affect all users.

Git Flow branching

Hotfix branches are used to address bugs and help bypass the develop branch. This allows developers to quickly fix issues without having to wait for the next release cycle.

The release branch contains the most stable version of the application and is what is released to users. This ensures that users always have access to a stable version of the application.

Git flow-based deployments solves the problem of deploying directly to production, which could introduce bugs and other issues. However, it has its own problems. Hotfixes take time to fix and merge into the release branch, then re-deploy. All users would be affected if the release branch has some bad code.

Git flow problems

Traffic Splitting Strategies​

To tackle these challenges, traffic splitting strategies have become more popular. This involves directing the flow of users between different versions of an application. This way, developers can test out new features and fixes without affecting all users at once. It's a way to try things out and make sure everything is working smoothly before making it widely available.

Blue/Green Deployment​

In a Blue/Green deployment, developers create two completely separate environments that are identical: one is the Blue environment, which runs the current application version, while the other is the Green environment, which runs the new version of the application.

Blue green deployments

To test out new features or fixes before making them available to all users, traffic is directed between the two identical environments in a Blue/Green deployment. However, this strategy still has a downside: if there's any bad code in either environment, all users will be affected. Even if it's just one new feature causing an issue, developers would still have to roll back all the features that were released.

Blue green deployment problems

Canary Deployment​

To address the problem of rolling back all features in a Blue/Green deployment, developers use a Canary deployment strategy. This involves gradually rolling out a new version of the service to a small group of users first. This way, they can test out new features on a small subset of users before making them available to everyone. This strategy minimizes the risk of introducing bugs or other issues and allows developers to make sure everything is working properly before deploying the new version to all users.

Canary deployments

Canary deployment has a lot of benefits over other deployment strategies, such as the ability to test out new features on a small group of users before rolling them out to everyone, reducing risk by catching issues early on, and allowing for more controlled rollouts by gradually increasing or decreasing traffic based on feedback and metrics.

However, it also has its own limitations. For example, it's not possible to independently test out features on different groups because features are released together in batches. This can make it harder to identify which features are causing issues or which ones are working well.

Canary deployment problems

Introducing Feature Flags​

Feature flags, also known as feature toggles or feature gates, are points in code that divide traffic and control which variation of a feature users are exposed to. They're typically used in conditional statements such as "if" statements.

Feature gates

Feature Flags

Local Feature Store​

Local Feature Store

A local feature store is a place where feature flag values are stored on the user's device. These values are often configurable by application users, which means users can enable or disable certain features based on their preferences. Examples of local feature stores include chrome://flags and firefox://about:config, which are settings pages within the Chrome and Firefox browsers respectively where users can toggle experimental features on and off.

Local feature store

One issue with local feature stores is that once an application is released to users, developers can no longer configure feature flags unless they release a new version of the application with updated flag values. This means that developers cannot easily change or test different feature variations without releasing a new update, which can be time-consuming and disruptive to users.

Local feature store problems

A remote feature store is a centralized location where flag values can be controlled remotely. This means that developers can modify feature flag values without having to release a new version of the application, and can target specific groups of users to see different features or experiences. Remote feature stores enable more dynamic and flexible control of feature flags, allowing developers to respond quickly to changes in user behavior or performance metrics.

Remote feature store

It's important to keep in mind that feature flags should only be used temporarily and should be removed once they have served their purpose. Keeping a large number of feature flags can cause performance issues, as it increases the size of the flagset payload transmitted over the network into the application.

Feature flags do provide a solution to the problem of releasing features independently, as traffic splitting can be controlled per feature. This means that features can be released independently to a subset of users, allowing developers to test and optimize new features before releasing them to everyone.

Feature Management Platforms​

There are many proprietary platforms available for managing feature flags, such as LaunchDarkly, ConfigCat, Split.io, StatsSig, and Rollouts.io. These platforms provide developers with a range of features and tools for managing feature flags, such as remote feature flag management, targeted rollouts, and A/B testing. They often offer integrations with popular development tools and frameworks, as well as advanced analytics and reporting capabilities. By using a feature flag management platform, developers can more easily control and manage feature flags, allowing them to release new features more efficiently and with greater control.

Flagbase

Absolutely! It's worth noting that there's also Flagbase, a free and open-source feature flag management platform. Flagbase is designed with performance in mind, and provides developers with the ability to manage feature flags easily and efficiently. With Flagbase, developers can control and manage feature flags remotely, target specific user groups, and conduct A/B testing, all for free. If you're looking for a feature flag management solution, be sure to check out Flagbase!

Here's a quick start guide: https://flagbase.com/docs/guides/quick-start/

That's a wrap! Happy Feature Flagging :D

In summary, feature flags are a valuable tool for developers to control the release of new features and target specific users. They enable the separation of feature releases from deployments, making it easier for developers to test and optimize new features before releasing them to everyone. With a feature management platform like Flagbase, developers can manage their feature flags more efficiently and keep their application performant. Regardless of which feature store is used, it's essential to remove feature flags once they've served their purpose. With these best practices in mind, developers can confidently roll out new features and improve their users' experiences. Happy coding!

Top comments (1)

Collapse
 
andrewdotdev profile image
Andrew MacLean

Love this article!