What makes Feature Flags a path to faster and safer development

Feature Flags (or Feature Toggles) is a way of working with code that allows teams to modify system behavior, without changing existing or deploying new code. It allows teams to handle deployments and new releases separately, and iterate rapidly.

Feature Flags vary by usage and context. Here we’ll look into three of the most powerful techniques that you can leverage:

• Trunk-based development
• Uncoupling deployments and releases
• Living on your product (aka dogfooding)

When getting started with this approach, your product doesn't necessarily have to be complex. Also the solution you choose doesn't have to cover every possible use case, at least not from day one. Teams can use popular SaaS solutions, open-source projects or just start with a simple JSON file in their repo, so don't be intimidated by how much is possible. The most important thing is to change your thinking when it comes to writing and releasing new code.

Trunk-based development enables engineers to check unfinished features into the main branch and safely release them into production at any time. When working this way, teams develop code in short-lived branches that enable developers to merge and deploy safely. This technique helps cut the time it takes to merge new code by avoiding the big, complex conflicts usually associated with long-lived feature branches. Checking in code regularly guarantees that teams can move quickly, without obstacles. To do this, teams use feature flags to disable unfinished code until it's time for release. When the feature is ready, simply enable the flag and release the new feature into the world. This allows teams to separate releases from the act of merging code. It also means moving from long development cycles to a series of short ones. Instead of big changes being merged at once, there are now lots of small iterative changes that are merged and deployed often, preferably many times a day. This helps teams move faster and safer.

Being able to tie a particular feature to a particular user, or a group of users, allows you to verify your ideas cheaply and safely. Аlmost every new feature in Readymag is released for internal users first — so our design team can test them thoroughly. It is especially powerful if you use your own product in your daily work, because your beta testers are right there working alongside you. Get feedback fast and test your ideas before you release a feature for the general public.

Feature Flags allow easy experimentation. Often there is some idea, maybe a concept for a new feature or a smart way of improving existing code, that needs to be tested. Using Feature Flags allows developers to explore these ideas in a real production environment without fear of breaking something. Try things out and see what's working, and what's not, then decide how to act on it later. Combine this way of working with monitoring and product analytics, and you'll get a really powerful combo!

So let's illustrate all of this with a real world example. Recently we launched new subscription plans for Readymag. To implement them, we needed to adjust some parts of our application that control available features and what limits are set for each plan. This is where Feature Flags help immensely. First, we added a new Feature Flag to our system. From there we wrote new code and adjusted the existing behaviour behind the flag. We did this over the course of many iterations, continuously deploying new changes into production. For example, the front end looked like this:

Here, we conditionally render a new part of the UI. Existing code works as usual until the flag is enabled.
Since we have two different components in this example, the team working on this can safely work on a new interface without disrupting the existing flow.
Elsewhere in our system we would have code like this, implementing another part of this update:

Of course it is always a good idea to test your code, especially when using something as dynamic as Feature Flags. So we did just that:

When we were ready to launch the update, we just enabled this flag and the feature was rolled out. Not only did this approach allow us to merge and deploy code continuously, it also made it possible to enable new code branches in several services at once without coordinated deployments.

Here are some best practices around Feature Flags that we use in Readymag:

• Feature Flags should have a short life cycle—they are used only before a feature is released, not to control long-term product behaviour.
• Always ask yourself if it would be easy to delete a particular flag later.
• Each Feature Flag is responsible for a single feature. It should have a name that is commonly understood.
• All flags should have similar semantics: all flags enable something, they don’t disable features.
• Sometimes it is better to duplicate code to ensure clean removal of the flag when the feature is released.
• Flags can and should be used for experimentation and to verify hypotheses.

So, the next time you're battling with some exhausting merge conflict, or you find your team holding on to some code because it’s too early for it to be released, or you wish that your team could try out some idea but it’s too dangerous, try using Feature Flags. Solve your problem at hand, and hopefully change your whole product development cycle for the better.