| There's a typo in the article: >Hardoced feature flags Think the author obviously meant "hardcoded" here. Anyways, recently, this has been really hard to sell teams on in my experience. At some point "feature flag" became equivalent to having an entire SaaS platform involved (even for systems where interacting with another SaaS platform makes little sense). I can't help but wonder if this problem is "caused" by the up-coming generation of developers' lived experience with everything always being "online" or having an external service for everything. In my opinion, your feature flag "system" (at least in aggregate) needs to be layered. Almost to act as "release valves." Some rules or practices I do: * Environment variables (however you want to define or source them) can and should act as feature flags. * Feature flag your feature flag systems. Use an environment variable (or other sourced metadata, even an HTTP header) to control where your program is reading from. * The environment variables should take both take priority if they're defined AND act as a fallback in case of detected or known service disruption with more configurable feature flag systems (such as an internal DB or another SaaS platform). * Log the hell out of feature flags, telemetry will keep things clean (how often flags are read, and how often they're changed). * Categorize your feature flags. Is this a "behavioral" feature flag or functional (i.e., to help keep the system stable). Use whatever qualifiers make sense for your team and system. * Remove "safety" flags for new features/releases after you have enough data to prove the release is stable. * Remove unused "behavior" flags once a year. My $0.02 |
> Anyways
I think you obviously meant "anyway".