We do have some features to help manage the lifecycle of feature flags. For example, we can determine when a flag has been "flipped on" for everyone, and notify you that it's time to remove it. We can also determine that a flag has been removed from your codebase, and prompt you to remove it from LD (http://blog.launchdarkly.com/launched-flag-status-indicators...).We have more coming, including an ability to mark "permanent" flags that should never be removed.
The product is built API-first-- everything in our UI is driven via our own REST API. Docs are here: http://apidocs.launchdarkly.com/
vinodkd|10 years ago
Can there be a feature switch that is configured not based on users, but on owner/admin's choice alone?
More importantly, how do the LD SDKs help with the issues mentioned in the "Implementation Techniques" section of Fowler's essay - things like avoiding conditionals, DI, etc?
jkodumal|10 years ago
re: conditionals, DI: our SDKs focus on the base technique (flags based on conditionals), but it's possible to wrap that core with higher-level approaches like DI, etc. We're considering going down that path, but where it makes sense to do so, and not have to re-implement higher-level wrappers for every framework out there. So, e.g.-- in Ruby, I can see us providing higher-level APIs specific to Rails.
Dependent feature flags are also an interesting problem-- we don't have a solution to that yet, but we do spend a lot of time thinking about feature flags, and I hope we'll have something on that front soon :)