4 ways of using Feature Flags like you actually know what you’re doing!

In the last article you saw how to add feature flags to your azure function application. There was just one simple dummy example on how to use feature flags, in this article we are going to look at a few ways where the feature flags might bring you value.

So without spending to much precious time let us dig in.

Avoiding the “upsies” ( aka. continuous delivery, while sleeping well at night)

The way this works, is quite simple, each time you start developing a new feature, you guard it with a feature flag. This ensures that, if your code compiles, and the feature is spread into multiple stories, you could push everything to your main branch, without the risk of breaking everything. Well, in theory at least. After you finished developing all the stories, and everything is pushed, you can just flip a switch, and boom!, the feature becomes active, no fireman or cowboy hat required whatsoever

Let someone else do it (aka. planned releases)

Wouldn’t it be great if you could just do your deployment for the upcoming big “release” a few days before the actual event and not have to be synchronized with this ( well this implies that the development is done a few days ahead, and all the testing was also completed, so this is applicable where possible) ? That would basically mean, that you do not have a very tight schedule for your release, you would do it in your own way and time. But how would you actually achieve this ?

Well let’s say you have this shiny new feature that everybody is waiting for, and the product manager announced that it will we be rolled out on Tuesday afternoon. In the regular way , the way you would go about it is that immediately after lunch you start the deployment process, if you are using blue / green or slots, push everything there, and when you get signal, you swap the slots, if you don’t ( you should start doing it, really … please use slots!) than, this is even more tricky to pull off, you need to know in advance how much time it takes to actually do the deployment, and start precisely so you will do it at that specific time, while people will anxiously click refresh on the page, not fun, not fun at all.

The cool way of doing this: when the story is done and tested, you push everything on master, with the feature flag on the prod environment set to off / false. Boom, your finished. You don’t need to be involved any further. Someone, can then just go in the feature flag app, and turn it on when the time comes. Awww yeeaah!!.

ProTip: Some of the more advanced feature flags tools also have something like planned activation 🙂

Word of caution: You should NEVER use feature flags when you are doing non-backward compatible database changes. Now that I am thinking about it, you shouldn’t do non-backward compatible database changes anyway, but here it is, you have been warned!

Achieving the singularity (aka. synchronize rollout in a distributed application)

One of the “few” challenges that you face developing distributed application, is that it is quite difficult to synchronize the successfully rollout new functionalities that cross multiple boundaries. I know, in your ideal project, nothing gets out of bounds, but some of us are not that lucky, and here is how we might be able to achieve this more enlightened state of synchronicity. Like in the above examples, use the feature flags to wrap all the functionality. Make all of them be based on the same feature flag. Again, deploy everything in a neat and timely fashion, and let someone else toggle the feature flag.

Step by step ( aka. Hierarchal feature flags)

Although, most of the feature flag management apps to not have a way to create hierarchical flags, there is nothing there to stop us doing this. One simple way of doing this would be to create a naming convection something like big-feature, big-feature.functionality1, big-feature.functionality2. This could help you gradually roll out functionality, and also have a much faster feed back loop in the dev — test/QA cycle. Meaning, that your testing people could be able to validate as you move from one story to the other and not having to do a “BIG BANG RELEASE” style of testing with 2 hours left before the deadline.

Word of caution

Now, as cool as they might seem, the feature flags are not a silver bullet, and will not fix all the issue of the world, but they do help provide some nice possibilities if used properly and responsibly. Also, I’m quite sure that for you to be able to successfully use feature flags, you will need to change a bit the way you are writing your code, in a m less procedural, more flow based way, and in some cases, you might have some duplication between the feature flags flows.

That is okay, as long as you are using it responsibly and after the validation of the new features, you go and remove all the guarded feature flags, and only leave the final version. If you fail to do this, than … well the “broken windows” principle kick in, and you end up in a big ball of mud.

If you liked the content, consider joining the list to get notified 😉

Originally published at http://laurentiu.codes on January 13, 2021.