Managing External Tools

Provide toggles to developers so they can enable or disable functionality like development tools, support system widgets, or other tools that aren't always needed in every environment.

• Disable analytics in development while making it easy for developers to enable when necessary so development and testing work don't skew the analytics.
• Selectively enable/disable troubleshooting tools so developers can turn the tools on and off in production without change code or re-deploying.
• Suppress customer-centric widgets for internal team members that don't need them so everything runs faster.

Let's considerer a tool like rack-mini-profiler. Would you ever want it on in production all of the time for each and every user? Probably not. You might however want to enable it in production for individual team members to troubleshoot a performance issue hasn't been reproducible in development.

Alternatively, would you want it on for everyone by default in development? That may be less of an issue, but for some teammates, the widget may get in the way of doing design or other front-end work.

Much of this could be handled with checks like Rails.env.production? or Rails.env.local?, but that can only easily consider the environment. And changing that logic would require re-deploying and the waiting that goes along with it.

With Feature Flags, everyone on the team can have more granualar control over which tools and widgets they want to see in which environment, and they can turn them on or off any time they want without any changes to the code itself—let alone waiting to deploy new code.