LaunchDarkly Blog
blog.launchdarkly.com · Company blog · on HN since 2015
Company blog of LaunchDarkly, a feature flag service, covering feature flag practices, testing in production, and release management.
What HN saysMostly company staff and users answer questions about feature flags, managing flag lifecycle and technical debt, and how the service compares with open source libraries.
31HN people shared it
5linked it in comments
62stories submitted
658story points
6 years agolast shared
2015people per year2026
Most-shared posts
- 1How to use feature flags without technical debt3 people · 60 points · first shared 2016 · 50 comments on HN
- 2Feature flagging to mitigate risk in database migration3 people · 24 points · first shared 2016 · 7 comments on HN
- 3Feature Flag-Driven Development2 people · 17 points · first shared 2015 · 13 comments on HN
- 4A New Way to Conduct Real-Time User Research2 people · 15 points · first shared 2016 · 2 comments on HN
- 5Feature Flags for Product Managers – The New Agile2 people · 9 points · first shared 2016 · 2 comments on HN
- 6Tonight We Monitor, for Tomorrow, We Test in Production2 people · 7 points · first shared 2018 · discussion on HN
- 7Adopting Feature Flag-Driven Releases1 people · 71 points · first shared 2016 · 39 comments on HN
- 8Visibility and Monitoring for Machine Learning Models1 people · 64 points · first shared 2018 · 6 comments on HN
- 9LaunchDarkly raises $8.7M for feature flag management1 people · 25 points · first shared 2016 · 4 comments on HN
- 10Implementing feature flags in single page apps, using React and Redux Saga1 people · 19 points · first shared 2017 · discussion on HN
- 11Go Serverless Not Flagless1 people · 17 points · first shared 2017 · discussion on HN
- 12Eliminating some of the pain of long-lived feature branches1 people · 14 points · first shared 2016 · 1 comments on HN
- 13[Podcast] to Be Continuous: When Toasters Broke the Internet1 people · 13 points · first shared 2017 · discussion on HN
- 14Feature Flag-Driven Products1 people · 13 points · first shared 2016 · discussion on HN
- 15Running Usability Tests in Production1 people · 12 points · first shared 2017 · discussion on HN
What HN people wrote when they linked it
yoz · 2020-06-22
I'm a Developer Advocate at LaunchDarkly, and we've written a bunch of different guides over the years. For a good intro that discusses first steps with flags and also how to approach testing flagged code, see our eBook "Effective Feature Management"[1] (Download page is right behind the form, you don't need to wait for an email or anything)
One of the best ways to start is add a simple kill-switch to low-impact code. (More about that in the book.) But, I have to ask: what are the main issues that are blocking you from starting? Is it that you need ideas for cases, or are worried about breaking something, or just want to ensure best practices from the start?
We're constantly writing new guides, both as blog posts[2] and long-lived guide articles on our documentation site[3]. Feel free to message me on Twitter[4] if you need more help!
[1] https://launchdarkly.com/effective-feature-management-ebook/
[2] https://blog.launchdarkly.com/
[3] https://docs.launchdarkly.com/guides
[4] https://twitter.com/yoz
pkaeding · 2016-08-03
I usually skip feature flags for things like bug fixes where the risk that my 'fix' is actually worse than the initial bug is very small, or changes where it cannot make sense to have both modes operating at once. An example of this might be a new billing scheme, where the old system billed by the item, and the new system billed by the pound. There might not be a technical reason why both cannot co-exist, but it would cause marketing/support headaches to have some customers billed one way, and some billed another.
One surprising use case that I have had great success with, though, is in database migrations. I detailed my approach here, if you are interested: http://blog.launchdarkly.com/feature-flagging-to-mitigate-risk-in-data…
eharbaugh · 2016-04-12
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-requirements-for-managing-feat…
segmondy · 2016-08-03
Checkout this article the author wrote in may, http://blog.launchdarkly.com/how-to-use-feature-flags-without-technica…
The idea is you create a branch to delete those conditionals before the feature flag is activated. Once it's activated, you merge in that branch.
jkodumal · 2016-04-13
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/