Feature Management — Part I

Delivering product features with safeguards

With the rise of continuous delivery, software teams ship new code to production all the time. But the rapid pace of change brings new kinds of risk.

In the old days, there have been months of testing and validation for each new deployment.

But for a team practicing continuous delivery, new code goes from the development team, through automated tests, and then directly to users in minutes.

So how do we manage and deploy features without affecting the existing system?

We get a lot of problems ahead before we try to find solutions.

Problems to solve

1. Building and maintaining features in the applications which are associated with other microservices. These features can be half-baked for other services to start with.
2. New Features need to be available only to some clients or a group of users who are ready to integrate features and use them in their own environments.
3. Testing and deploying certain features only in specific environments. Clients request certain features only for them and are available only on their servers.
4. Restarting servers, redeployment, and rollback features on server level rather than an application level.

Feature Flags to the Rescue

A feature flag is a decision point in your code that can change the behavior of your application. It is also known as feature toggles — have long been used to trigger “hidden” code or behaviors without having to ship new versions of your software.

Benefits

1. Enables businesses to dynamically control the availability of application features to end-users.
2. Developing major features in partitions with no fear of getting executed, cutting long development costs and high development responsibility within or outside of the application.
3. Deploying and testing application empowering features with application control rather than environment control.
4. Easy plugin and play features which are visible to end-users and easily configurable by various teams — development and operations engineers to product and marketing managers.

As the team grows, it becomes necessary to create such product features that guarantee system redundancy such that the product is able to survive failures with a predictable outcome.

Any major features can be developed simultaneously with the sprint releases and can be kept hidden until it is fully completed. Your code can live up to thousands of years until you set the flag on and maybe more!

Developers, product teams, or DevOps do not have to worry that the production environment is on fire because of a TYPO!!

Enable completed features whenever you want to showcase to the clients without any deployments!

Ship when ready!

Decoupling deployments from releases will give flexibility in rolling out the features with a release strategy. Business can have a progressive delivery — the ability to strategically control when individual users or user segments gain access to new features.

Feature Flags will enable the following flexibility in the company.

01 | True continuous delivery

02 | Test with real, live users

03 | Roll out features to limited users

04 | Receive user feedbacks

05 | Experiment and Monitor

Stay in Control

With feature flags, the product is always focused on its stability and minimizing the risk in the production environment.

Flag Early and Often.

As a complement to customer-visible feature flags, these “operational feature flags” give DevOps teams powerful controls that they can use to improve availability and mitigate risk.

Safety Valves and Circuit Breakers

Permanent feature flags that you can use to quickly disable or limit nonessential parts of your application to keep the rest of the application healthy.

Add temporary/permanent feature flags.

Develop new superpowers to ship when you’re ready, test in production.

Infrastructure Migrations

Decompose the problem into multiple steps, with each step controlled by a feature flag that you can rollback.

Implementation

Feature flags can be a simple if-else statement in the application code that directs the application flow based on its values.

For more implementation details, you can go through my presentation slides here.

Voila!! That’s all for the first part! Read Part II here.