Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Feature flag management for feature lifecycle control

launchdarkly.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Show HN: Feature flag management for feature lifecycle control

#11

Post by omegaworks »

eharbaugh wrote: post #7
misterkwon wrote: post #3

can't you just use an open source library for this? how many feature flags would you even need for this to be worth it?

Good question - teams should do what’s best for them based on their resources and scope of feature flagging needs. Though open source libraries exist, they're per language (Ruby, Python). We offer support for all major languages + iOS. As well, we have environment support and access control levels to use feature flags effectively throughout development. You can read more here: http://blog.launchdarkly.com/enterprise-…

Any hope for Android support?

Re: Show HN: Feature flag management for feature lifecycle control

#12

Post by tldnr »

Seems like a great product! Our inhouse flagging system is painful to use when applying features en-masse, and makes "fast" rollbacks virtually impossible. That, and other reasons, make this seem like a good alternative.

What's the flow like for a developer creating their own environment? I'm a little concerned that asking developers to visit a third party site/be connected to the internet to use feature flags locally be pretty inconvenient, especially if the developer is working offline. Would you consider adding a simple server implementation that could run locally and do feature flagging on a per user basis (rather than rolling out to percentages, to prevent misuse)?

Re: Show HN: Feature flag management for feature lifecycle control

#13

Post by eharbaugh »

omegaworks wrote: post #11
eharbaugh wrote: post #7

Earlier quoted context omitted.

Good question - teams should do what’s best for them based on their resources and scope of feature flagging needs. Though open source libraries exist, they're per language (Ruby, Python). We offer support for all major languages + iOS. As well, we have environment support and access control levels to use feature flags effectively throughout development. You can read more here: http://blog.launchdarkly.com/enterprise-…

Any hope for Android support?

Yes, we are planning on adding Android this summer. Are you interested in being a beta user? Write us at support at launchdarkly.com

Re: Show HN: Feature flag management for feature lifecycle control

#14

Post by pkaeding »

tldnr wrote: post #12

Seems like a great product! Our inhouse flagging system is painful to use when applying features en-masse, and makes "fast" rollbacks virtually impossible. That, and other reasons, make this seem like a good alternative. What's the flow like for a developer creating their own environment? I'm a little concerned that asking developers to visit a third party site/be connected to the internet to use feature flags locall…

For local development, you can create an 'environment' for each dev, which will maintain a separate set of targeting/rollout rules for each feature. This will make development/testing fast when you are connected to the Internet. You can flip the toggle value on the LaunchDarkly dashboard, and it will be instantly updated the next time your code gets the feature flag.

You can also provide a default value that will be used if the network is not available. You can read from a config file to drive this if you need to, to allow devs to specify the flag value when offline. This is what we do for our dogfood environment (prod, staging, and dev environments all talk to dogfood, but dogfood doesn't have another LaunchDarkly to talk to).

Hope that helps!

Re: Show HN: Feature flag management for feature lifecycle control

#15

Post by vinodkd »

eharbaugh wrote: post #2

Hi, I’m Edith Harbaugh, CEO & co-founder of LaunchDarkly. Feature flagging/toggling is a best practice of continuous delivery. Feature flagging is easy - you can do it with a config file or a database field. However, once you start feature flagging at scale, your feature flag config files can become a junk drawer & a form of technical debt. LaunchDarkly is a feature flag management system that allows you to scale up.…

So how exactly does launchdarkly help with feature flags becoming a junk drawer/tech debt? I can see how the intuitive ui would help in general, but what I was really expecting to see was:

* A way to manage dependent feature flags, because god knows once those non-technical(and technical) users have switches they can throw, they're going to ask for/build features that are dependent on each other in subtle ways

* A distinction between a true feature flag and what I call a "release" flag, ie, a feature that's not yet fully built, but that will not be optional once fully built and released, so its flag goes away at some point.

Also, btw, do you have an API for the flag creation itself, not its use, ie a addFlag()/removeFlag() API?

Re: Show HN: Feature flag management for feature lifecycle control

#16

Post by true_religion »

misterkwon wrote: post #3

can't you just use an open source library for this? how many feature flags would you even need for this to be worth it?

It's feature flags + AB testing with a nice interface for non-programmers to twiddle with and analyze the results.

It's basically the same market as Optimizely.

Re: Show HN: Feature flag management for feature lifecycle control

#17

Post by jkodumal »

vinodkd wrote: post #15
eharbaugh wrote: post #2

Hi, I’m Edith Harbaugh, CEO & co-founder of LaunchDarkly. Feature flagging/toggling is a best practice of continuous delivery. Feature flagging is easy - you can do it with a config file or a database field. However, once you start feature flagging at scale, your feature flag config files can become a junk drawer & a form of technical debt. LaunchDarkly is a feature flag management system that allows you to scale up.…

So how exactly does launchdarkly help with feature flags becoming a junk drawer/tech debt? I can see how the intuitive ui would help in general, but what I was really expecting to see was: * A way to manage dependent feature flags, because god knows once those non-technical(and technical) users have switches they can throw, they're going to ask for/build features that are dependent on each other in subtle ways * A di…

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/

Re: Show HN: Feature flag management for feature lifecycle control

#19

Post by vinodkd »

jkodumal wrote: post #17
vinodkd wrote: post #15

Earlier quoted context omitted.

So how exactly does launchdarkly help with feature flags becoming a junk drawer/tech debt? I can see how the intuitive ui would help in general, but what I was really expecting to see was: * A way to manage dependent feature flags, because god knows once those non-technical(and technical) users have switches they can throw, they're going to ask for/build features that are dependent on each other in subtle ways * A di…

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…

Thanks for the response. This is the confusing part for me: I've been talking in terms of Feature toggles as described by Martin Fowler: http://martinfowler.com/articles/feature-toggles.html, but it looks like LD is focusing on the AB testing piece primarily, with some parts of the base toggle functionality included by default.

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?

Re: Show HN: Feature flag management for feature lifecycle control

#20

Post by dang »

kzhahou wrote: post #18

In the spirit of the HN community feel, "Show HN" has always been about personal, side, or small projects. Never a link to a company's page.

Oh no, that's mistaken. Show HN is for something you've made that people can try out. The project can be, and often has been, a company with customers.
Post reply on HN