Using Feature Flags + Logging for Effective Debugging

Myth: Feature flags = feature toggles. 

Truth: feature flags can toggle your features on and off and do so much more. Today, we’ll explore how you can use feature flags to turn on logging for a specific user to identify and fix a bug quickly for them. 

TechWave's Challenge: Unraveling the DataCo Bug

TechWave, renowned for its cloud-based analytics solutions, has been serving a large data analytics firm for years. Recently, a user from one of their customers, DataCo, reported a bug where certain data visualizations failed to load correctly for them, affecting critical decision-making processes.

TechWave’s Support Team Lead spent 3 hours on a call with this user to try and find out where the bug was stemming from, to no avail. They realized this bug was likely being caused by something in the configuration that wasn’t easily recognized as a bug, and that they’d need a different solution. So, their dev team determined that they would need to use feature flags to turn on logging for this user, and debug in real time. Here’s how they did it.

Step one: Set up logging

TechWave makes use of centralized logging for their applications allowing for developers to see all the log files in one place no matter where the log message comes from.  However, the section of code where they were going to add the logging is used by all users of the application. Therefore, it would create a lot of unnecessary log messages, so they wanted to only log messages for a specific group of users.  

Step two: create the feature flag, and enable it for specific users

Then, the devs created a feature flag called tw4356-env-config to surround logging and enable it for the user who reported the bug, as well as users who have reported similar issues. By doing so, they’ll receive log messages for only the users who may be experiencing this bug. The reason their dev team didn’t want to hard code the user information in the conditional for the log message  is because they had been receiving complaints of a similar issue from other users earlier that week. Enabling the feature flag for an audience rather than only one user allows them to address this bug on a larger scale.

Step three: Create another feature flag!

After some digging, TechWave’s developers felt that the bug could be originating from two different areas within the configuration. So, they decided to create another feature flag, called tw4356-db-config. They can control the logging for each feature flag separately to determine where exactly the bug is coming from.

Step four: Deploy feature flags with CD and enable them for the necessary users

This isn’t necessarily a “step” but it’s important to note that TechWave is able to enable these feature flags and identify the bug seamlessly, because they have a strong CI/CD pipeline in place. Rather than having to wait days or weeks to create the flags and deploy, they’re able to  see the log files and identify the bug within 30 minutes. 

‍Step five: Fix the bug, and clean up those feature flags!

TechWave identified the bug and found that it was created by the relationship between two different pieces of the application and how they interact with each other, which would explain why it was hard to detect in the first place. After successfully fixing it, it was time for the devs to clean up the two feature flags and take out the logging they had set up. And with DevCycle’s code clean up, this type of maintenance was easier than ever, as our utilities ensured the feature flags wouldn’t get lost, and were ready for removal.

Wrapping up

As TechWave and countless other feature flag users prove true, feature flags are much more than an on/off toggle. From aiding in effective debugging, to database migrations, internal testing, user gating, and more, the possibilities are endless.

If you’ve got a use case in mind, we’ve got a feature flag for it. Get started today.