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

Show HN: Dorkly – Open source feature flags

github.com

Post reply on HN
Print view View original

61–70 of 104 posts

Re: Show HN: Dorkly – Open source feature flags

#61

Post by teeray »

wfme wrote: post #41
ryanmcbride wrote: post #35

Earlier quoted context omitted.

So you just flip feature flags in prod all willy nilly? No process?

There are more options than store in git, or flip willy nilly. For systems of sufficient scale, it's fairly standard to keep flag changes outside of git so that they can be flipped without a pr. That way the flag change UI can apply other validation steps before any change is attempted such as ensuring valid enrolment ranges (no accidental overlap, and no accidental rollouts to 100% instead of 10%), and the associate…

Chatbots are great for this too. You get flippiness, but you also get auditing implicitly from the chat log.

Re: Show HN: Dorkly – Open source feature flags

#65

Post by hardwaresofton »

rekoros wrote: post #9

If you’re looking for an open source feature flag option, also check out https://www.growthbook.io/

There are... a bunch of them. I write a little blog (soon to be directory site) about open source and at this point I groan a little bit when I see another one (wonderful problem to have of course):

https://awsmfoss.com/flagsmith

https://awsmfoss.com/unleash

https://awsmfoss.com/featbit

https://awsmfoss.com/flagr

Re: Show HN: Dorkly – Open source feature flags

#66

Post by mosselman »

teeray wrote: post #60
randerson wrote: post #48

Earlier quoted context omitted.

The sole reason I like feature flags is that I can quickly toggle off a change if it causes a problem. I'd hate to need to find someone to sign off on restoring service. Anything more than 1 or 2 clicks is just adding precious seconds to an outage. I've worked at places that gave broad implicit approval to developers to toggle away as needed. It worked well.

> I'd hate to need to find someone to sign off on restoring service. In these shops, this gets handled via paging on-call engineers. The on-call is sometimes given more latitude if their actions are auditable.

Imagine being called out of bed to turn off a feature flag.

This is nonsense.

Re: Show HN: Dorkly – Open source feature flags

#67

Post by hinkley »

bottd wrote: post #58
hinkley wrote: post #49

Earlier quoted context omitted.

But it’s also common to stick those flags back under some sort of audit system so we know why and how weird states got set. The simplest way is a separate repo with simpler rules for pushing to master. Though you could also create your own audit system (just make sure it functions even when the entire site is down)

This is all decided by business needs, not by engineer preference. If devs aren’t pulling the levers it is good to expose them in an accessible interface, not plaintext.

Let’s not pretend like these “business needs” don’t often boil down to a couple of tropes and that the story doesn’t change after a couple of post mortems are turned in for perfectly predictable failure modes.

Re: Show HN: Dorkly – Open source feature flags

#68

Post by solatic »

danpalmer wrote: post #37
snapcaster wrote: post #5

If it's something controlled by the PR why is it even a feature flag? Seems like you lose a huge chunk of the benefit and might as well just change the code at that point. This to me seems like the wrong place to be controlling them, i certainly don't want to have to make a PR and merge it when a site issue is happening. Open to missing something though, curious what others experience has been

It's good to have the current state of all the flags in source control, just like you do for things like infrastructure-as-code. The distinction is that you have a different release process, or build a different artifact, from your main codebase. The codebase you are controlling with flags doesn't change when your flags do. This can be done with separate repos if you want one build per repo, but it doesn't have to be…

If you split feature flags into a different repository, then you're losing the benefit of having everything in a single repository, of having consistency and avoiding situations where your codebase refers to feature flags that don't exist, old feature flags that are no longer checked by the codebase, etc.

At this point, your production infrastructure is no longer solely one stateless server + one database, but two databases: your RDBMS and your GitOps repo tracking feature flags. Do you really get enough value from the second GitOps database compared to putting your feature flags in your main RDBMS?

Re: Show HN: Dorkly – Open source feature flags

#69

Post by icansearch »

theogravity wrote: post #27

Neat! I'll look into integrating this with my feature flag abstraction library: https://github.com/theogravity/feature-manager-wrapper Edit: It looks like it's a backend replacement to LaunchDarkly, but you can still use the LD client from what I'm reading here, so there's nothing for me to integrate here.

Similar to https://openfeature.dev/ ?
Post reply on HN