For the next few days I’ll try to share a few of the discussions before, during, and after devconf, a community driven, developer focused, one-day conference hosted annually.
Feature flags are definitely a hot topic. Here are some of the questions we discussed over the past 2 days and my thoughts.
How do we use feature flags in VSTS?
Buck’s feature flags blog post and his presentation/article are a great source to get an understanding of the custom-built feature flag system we’re using with Team Foundation Server (TFS) and Visual Studio Team Services (VSTS).
Do the Rangers use the same FF as VSTS?
Are feature flags free?
No, they introduce additional testing - for as long as a feature flag is in the code, you need to test all possible ways that the code could run using boolean (true, false) or multi-value flags. Sounds easy for a handful of flags, but when you reach hundreds of flags you’ll have a complex test plan to ensure all possible code paths are functional.
Then there’s the maintenance – deciding when and how to delete feature flags in your code. We expect our autonomous, self-organizing, and self-managing teams to take care of the feature flag maintenance and deleting stale flags. When you’re using LaunchDarkly you get a visual flag status on the dashboard, making is easier (not easy) to identify flags that are stale and candidates for deletion.
When do we remove feature flags?
We have no process (yet), relying on feature teams to decide when to delete their feature flags. As Buck states “Many feature flags go away and the teams themselves take care of that They decide when to go delete the feature flags. It can get unwieldy after a while, so there’s some natural motivation to go clean it up. It’s easy– you delete things."
We’re still in an exploratory stage, looking for ways to identify stale feature flags and ensuring that they are deleted to avoid lingering technical debt that will haunt you.