How do you safely roll out your features to end users?

How do you safely roll out your features to end users?

How do you do A/B testing of your feature?

How do you quickly roll back a change?

How do you do CI/CD when your code can be unstable?

When you think of agile, CI/CD, faster roll outs, you might be having these questions in your mind and you might be thinking how they do it! When you’re part of a development team getting your hands dirty with coding, you may agree that it’s not damn easy to have a smooth ride.

Well, there’s a way that can answer all of these questions and it’s called feature flags!

Feature flags, also called as feature toggles or switches, is a very effective concept that helps businesses to roll out new features quickly and safely. It’s basically a switch added while developing the feature that can be turned on and off without any code change or deployment.

Why are those needed?

As agile development and CI/CD processes are gaining more and more adoption, it becomes imperative for development teams to keep their main or master source code branch production-ready always. In practice, that’s far easier said than done.

Imagine the real world situation — Your team is working on feature A, B & C development at the same time. Here, feature A is completed, verified & ready to go to LIVE, but feature B & C whose code is also merged to your main branch (since you’re also doing continuous integration), are not ready yet.

How do you only let feature A go to LIVE? You might say, I would comment out code related to A & B or I would create a new branch, cherry-pick commits of feature A & deploy that branch. Now, these approaches can get your job done, but they definitely aren’t scalable. You can’t do that all the time.

That’s where feature flags really shine and make things easier for you. You can just wrap the code (of course, not entire but the entry point) related to newer features with the condition and set the value of that condition (e.g. true or false) using the feature flag management dynamically. In this way, your team doesn’t need to be worried about letting incomplete, half-baked, unverified code getting deployed to LIVE.

What are the benefits?

The feature flags aren’t only useful for shipping your code to production quickly & safely. They give you a lot more power to do things which your business will certainly appreciate. The benefits of feature flags are,

• Safer feature roll outs — deploy the code confidently
• Gradual rollout — enable the new feature gradually to all of your users
• Quicker rollbacks — if something is broken with new features or because of newer code, you can quickly turn off the switch, phew! This is far more useful than just rolling back a broken feature. Consider a scenario where your system is flooded with the traffic to some resource-heavy features degrading overall performance of the system. Now, you don’t want to let some of those features take down your entire application. Having feature flags gives you additional ammunition to tackle the situation in a better manner. To cool down the application infrastructure resource utilization, you can take a call on disabling certain resource-hungry features by killing the switch. You can do it for all users or for some users. Now, this may not be the best way always, but it’s good to have few tricks up your sleeve
• Enables A/B testing — experiment with the new feature or design, get the early feedback from the selected users
• Effective CI/CD Pipelines — the ability to keep your main or master branch always (or mostly) production-ready makes it easy to enable CI/CD pipelines, helping businesses to please the users with faster code shipping
• User customizations — you’re now armed to give users personalized experience, as feature flag tools can make decisions based on what user it is serving

Unleash

From the website:

Unleash is a feature toggle system, that gives you a great overview of all feature toggles across all your applications and services. It comes with official client implementations for Java, Node.js, Go, Ruby, Python and .Net.

Unleash is an open-source and free system which you can use to manage all of your toggles. It gives client SDK for various languages. Unleash also has enterprise edition which is maintenance-free, managed, multi-tenant, secure solution with some additional capabilities over open-source edition.

Unleash also gives you an user-interface out of the box which you can use to monitor & manage all of your toggles. You can add toggles, define the strategies to be used, track the status & history each toggle.

I will explain some of the Unleash concepts here & give technical details.

Unleash context

Unleash uses the context data which is ideally specific to a particular user request, to decide whether to make the switch on or off. The context usually contains userId, sessionId, remote IP address, environment, etc. You can customize and add more fields as per your application requirements, such as user role, user device name, browser, etc. The context data is used by Unleash activation strategies to take the decision.

Activation Strategies

A strategy is a condition or set of conditions that you define which finally tells “yes” or “no” to the user requests. That means, strategy uses the unleash context and based on the input it runs defined conditions which gives a boolean answer (remember it’s just a toggle/switch) whether to allow or disallow the user request. Unleash comes with some predefined strategies out of the box. It’s easy to define your own strategies so you can define criteria as per your need.

Technical Details

If you’re interested in using Unleash in a self-hosted manner, then you should know the technical details of it.

Unleash Service: It’s a Node.js application that actually does all the heavy lifting. It has an implementation for Unleash API & the UI.

Database: Unleash uses PostgreSQL to store toggles states.

Feature flags naming convention

While there’s no defined standard, I can suggest a practice which will keep toggle names consistent, readable and manageable.

We can use a pattern as given below to name toggle.

Product — Application- Module — Feature — Sub feature 1 — Sub feature 1.1 and so on.

Here, you can use a dot (.) or any other separator as you prefer, to separate the words.

For example, a toggle name can be defined as,

uber.rider.trip.payment.receipt.download_pdf

Problems with feature flags

As they say, all good things come with the price. Feature flags are no exception to that.

How to track them?

As your application keeps on growing and you’re using feature flags extensively, at some point you’ll soon start losing the track of them. What is the state of flag ABC or flag PQR…? Does that toggle condition still exist in the code? What is the strategy applied? You will surely be asking those questions. But, what is the solution?

Well, there isn’t an easier way to do this, at least to my knowledge. Comments are welcome. Atlassian uses feature flags in their product development. In one of their blogs, they briefly describe how they track their feature flags. You can read it here. Atlassian uses a kanban board with a workflow that is used to track the state of each flag. They also have automated it by integrating their feature flag tool with JIRA.

Ever-growing technical debt

Well, when using feature flags you’re paying a huge price of increasing technical debt if you’re not careful enough. When your feature is fully rolled out, you would require to remove the toggle related code from your codebase. But, it has various complexities associated with.

Each flag requires you to add a condition in a code. In the real world, this condition may be required to be added at multiple places, if you have multiple entry-points for your feature. Once you roll out your feature to all the users, ideally you should spend efforts to remove the toggle related code, correct? Now, I’m talking about an ideal world, but it’s not the case everywhere, is it?

As your code base grows, it becomes very difficult to go back to the flag code, analyze it and plan to remove it. This may sound easier but it’s not. Maybe that flag was added some months back, or the developer who has added it, is on long vacation or has left the organization. And, by now you’ve a lot of newer lines of code added which makes it very difficult to figure out exact code changes and their side-effects.

It’s always advised that you consider this technical debt as important. Having unnecessary toggle code also impacts the overall performance.

References

https://martinfowler.com/articles/feature-toggles.html

https://dzone.com/articles/feature-toggles-are-one-worst

Please comment below if you have different thoughts or want to give any suggestions about the article content. I would appreciate it.