Q&A

Get Good at DevOps: Feature Flag Deployments with ASP.NET WebAPI

• By David Ramel
• 10/03/2024

Feature flags have become an essential tool in modern software development, particularly for DevOps and continuous delivery. They provide developers with the ability to toggle features on and off without having to redeploy code, making it easier to manage risk, test features in production, and facilitate smoother releases.

But how do feature flags work, and why should teams prioritize their implementation?

Those questions will be answered in the upcoming presentation, "Get Good at DevOps: Feature Flag Deployments with ASP.NET & WebAPI." Helmed by expert author, trainer and developer Ben Day, it will dive into the benefits of feature flags, how they fit into Agile and Scrum practices, and how to use them effectively in ASP.NET and WebAPI projects. Ben will walk through the process of integrating feature flags into a deployment pipeline, demonstrate how to avoid common pitfalls, and explain how this practice can improve team collaboration and productivity.

Here's a short Q&A to learn more about the session, which is taking place at the big Live! 360 tech event in November at Universal Orlando, where co-hosted dev/IT conferences focus on Visual Studio, Data, AI, Cloud & Containers and Cybersecurity & Ransomware.

VisualStudioMagazine: Briefly, what are feature flags, and how do they differ from traditional deployment strategies?
Day: Feature flags are often referred to as "feature toggles." It's a fancy way of saying that you're wrapping features or versions of a feature inside of some kind of conditional "if" block.

With a traditional deployment model, you deploy whatever is in the compiled code. So if you don't want a feature to appear in your application, you can't put that in the code. If it's in the code, it gets deployed. And if it's deployed, then that feature is live.

That traditional model is super straightforward as it related to deployment. If you're thinking about just deployment, then it's easy. But when you're working on a big, complex system with lots of team members or even possibly multiple teams of multiple team members, that ease of deployment starts causing complications for the teams.

What was the problem before using feature flags, and how did they resolve it?
This gets a little complex and might be sllllightly long-winded.

So let's say that you're working on one of those complex applications with a couple different teams. They're all trying to work on features and those features are in various states of readiness -- and probably, if we're honest -- various levels of quality.

A great example of where life gets tricky is with version control. You'll probably be releasing to production from your "main" branch (or "master" or "trunk" or whatever you call it). The teams will do their features in "feature" branches off of the main branch. If you want to release the feature, you get the code for that feature merged to main.

Ok. So merge one feature and that's easy. Merge two features and that's less easy but not that bad. But more likely, you're merging a whole bunch of features from multiple teams. Those features have to get merged together to know if any of them are working. The more feature branches that are wrestling to get merged into main, the harder it gets. It's a lot of effort.

And then what happens when you merge five feature branches .... and then it turns out that the third feature you merged was a total stinker. How do you keep the merges for Features 1, 2, 4 and 5 but un-merge Feature 3's code? How do you un-ring that bell? How do you unmerge just that one feature? There really isn't a great answer…

... except for using feature flags.

With feature flags, you don't really care. Your features all have a configuration value that makes the feature available or not available. Merge the code with all five features -- including the notoriously wonky Feature No. 3. Build the code. Deploy the code to production. But when you get to production, simply set the feature flag for Feature No. 3 to "off."

Problem solved.

Much much less worrying when it comes to merging. And this is just one of the benefits of using feature flags.

What are some key challenges developers face when integrating feature flags into their applications?
I'm not gunna lie -- adding feature flags adds complexity. It also adds some maintenance overhead. In an ideal world, you'd deploy your code and that'd be it. It's done. It's written. Move on to the next thing.

Well, with feature flags, you probably don't want to just leave them hanging around. Eventually, you'll want to remove the feature flag and make the feature simply just available in the app. Put another way, eventually, you'll feel good and confident about the quality of that feature and you'll remove the feature flag complexity for that feature.

You have to schedule that feature flag removal work and remember to actually do it. Otherwise, you end up with 9 billion feature flags sprawling all over your codebase.

In what ways do feature flags support Agile methodologies and Scrum practices?
Myriad ways. The big one is that feature flags supports Agile QA testing. It really takes the pressure off of having to be 100% sure that that new feature you're working on is really truly definitely without-a-doubt working perfectly.

Feature flags let you make little mistakes quietly.

Let's say team feels good about Feature Xyz that's going live. They push the code live and enable the feature flag and now the world can use Feature Xyz.

But then it turns out that this new feature just plain stinks for performance. It's slowing down the whole web application.

If you're not using feature flags, this is a nightmare scenario. "OMG! We're gotta roll back the build!!!"

With feature flags, just flip the configuration from "on" to "off." The feature disappears. Performance has just gone back to normal. You now know you have some kind of a bug in that feature that needs to get fixed before you can go live again with that feature.

It's not great when this happens but what used to be a Big Deal has just turned into a minor annoyance. You learn from your mistakes. You fix your problems. You recover quickly and you live to fight another day.

How can attendees and other developers stay updated with the latest best practices and tools for feature flag management?
Well ... they should come to my talk and find out!

Kidding aside, feature flags really aren't that complicated as a technology practice. The implementations though can range from "simple" to "insanely complex." My recommendation would be that attendees should start simple and just play with their own home-grown feature flag implementation at first.

So far, I've only mentioned the DevOps/deployment benefits of feature flags. There are other benefits, too -- for example ways to help your product ownership team and ways to support beta testing or A/B testing. Start simple but if you and your team want to start getting into more advanced options, then they might want to look into using a third-party product like LaunchDarkly.

Note: Those wishing to attend the conference can save hundreds of dollars by registering early, according to the event's pricing page. "Save $400 when you register by the Extended Super Early Bird deadline of Oct. 4!" said the organizer of the event, which is presented by the parent company of Visual Studio Magazine.