Over a million developers have joined DZone.

How to Use Feature Flags Without Technical Debt

Or, won’t feature flags pollute my code with a bunch of crufty if/then branches that I have to clean up later?

· DevOps Zone

Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs

People often ask for advice on maintaining feature flags after they roll out the new code to all users. Here is one way to approach the issue of cleaning up the old code paths. It works pretty well for our team. If you have any other ideas, please let us know!

Write the New Feature

Step one is to write the new feature, gated by the feature flag, on a short-lived feature branch off of master (call it pk/awesome-xyz-support):


...

ifldclient.toggle('temp-awesome-xyz',user,false):

do_the_new_thing()

...

else:

do_the_old_thing()

...

Next, before you submit your pull request for this change, create a second branch, off of the first, and call it cleanup/awesome-xyz. This branch removes the feature flag, leaving just the new code:

Conventions

There are a couple of naming conventions I used here:

  • The feature flag is prefixed with temp-. This signals that it is meant to be a temporary flag, and is intended to be cleaned up at some point in the future. This is different from permanent flags, like ones relating to maintenance mode.
  • The cleanup branch is named cleanup/${FLAG_NAME}. This signals that it is intended to clean up that flag. This will be useful if you are scanning the list of branches later on.

Submit Your Pull Requests

Submit the first pull request, with your feature branch targeting master. When it passes code review, merge and deploy as usual.

Next, submit the second pull request. Don’t merge it until you are satisfied that everything is good with the new code, but you can have your team review it while the other changes are in the front of everyone’s mind.

You can use the flag status indicators to give you an indication when it is safe to merge the cleanup branch because all users are getting the new variation.

Why Do It This Way?

The advantage to managing cleanup this way is that you do the work to remove the flag when all of the context is fish in your mind. At this point, you know all the pieces that get touched but he change, and it is easier rot be sure you don’t forget something.

You will need to merge master back into your cleanup branch periodically, but that is usually easier than it would be to recall all of the context relating to the original change.

This is certainly not the only way to handle this issue, but it seems to work pretty well for our team. I’d love to hear how your team handles cleaning up feature flags!

Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.

Topics:
feature ,flags ,code review ,feature flags ,status

Published at DZone with permission of Patrick Kaeding, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}