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

41–50 of 104 posts

Re: Show HN: Dorkly – Open source feature flags

#41

Post by wfme »

ryanmcbride wrote: post #35
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

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 associated rollout analytics can be shown alongside the changes.

You can also override things in emergencies more easily, which is the parent's point.

Re: Show HN: Dorkly – Open source feature flags

#42

Post by yoz »

esafak wrote: post #28

I would expect an open source feature flag solution today to support https://openfeature.dev/

And it does, because it uses LaunchDarkly SDKs: https://docs.launchdarkly.com/sdk/openfeature

... though there are only three officially-supported OpenFeature adapters so far (Java, NodeJS, .NET)

Re: Show HN: Dorkly – Open source feature flags

#43

Post by goosejuice »

_corym wrote: post #32
kageiit wrote: post #30

Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.

My team leverages feature flagging heavily. Developers want to clean them up but product doesn't prioritize the tickets, and it creates more burden for QA as well having to do a full regression test.

Sounds like a great reason to include cleanup as part of the initial work.

Re: Show HN: Dorkly – Open source feature flags

#44

Post by alienchow »

Nice, thanks for sharing. I've been looking for an alternative to CDPush (Google's internal version controlled config push).

Unaudited, untracked web UI based feature flagging has been my peeve with the other solutions. I'm surprised all the feature flagging solutions out there don't have this as a default. The next step would be to use an artifact versioning repository to decouple from S3.

Re: Show HN: Dorkly – Open source feature flags

#45

Post by willsmith72 »

wewtyflakes wrote: post #25
drichelson wrote: post #12

Earlier quoted context omitted.

The PR is optional, but governance often requires documented peer approval for all production changes. Flag changes can be pushed directly to the main branch with the correct repo permissions. When using the GitHub UI this involves just a little bit of typing and a few clicks. >might as well just change the code at that point If changing the code, running tests, building, and deploying is quicker and less risky then…

This seems like a reach. A nice benefit of having these server-owned configuration flags with a slick UI (like launchdarkly) is that they can be modified by people on the fly, and by people who may not even be engineers (like product managers). I imagine, that if the ask is that they instead get GitHub permissions, make a PR, wait for a review, etc, then perhaps you are not competing with launchdarkly. Though, having…

Depends on the feature. In 99% of cases, I'd prefer an engineer to launch it and have the change tracked by source control

Re: Show HN: Dorkly – Open source feature flags

#46

Post by willsmith72 »

_corym wrote: post #32
kageiit wrote: post #30

Feature flags are great for safely releasing features fast. As you add more of them though, they add tech debt and make the code harder to reason about. Developers are rarely motivated to clean them up after rollout.

My team leverages feature flagging heavily. Developers want to clean them up but product doesn't prioritize the tickets, and it creates more burden for QA as well having to do a full regression test.

The issue is not about feature flags then.

It's stakeholders not giving engineers necessary time for upkeep, probably caused by engineers lacking ownership, or failing to communicate

Re: Show HN: Dorkly – Open source feature flags

#47

Post by willsmith72 »

drichelson wrote: post #4
hiatus wrote: post #2

I like the idea of the flags being managed via normal change-management processes. In your experience, is it primarily developers in charge of enabling/disabling flags or have you seen responsibility diffused across departments (marketing, sales, etc)?

I have mostly seen developers in charge of changing flags, but there is also great value in empowering other roles to change flags (One example: sales people can unlock features as they sell them). Thankfully GitHub has an easy web-based Pull Request process. It's not as simple as a custom UI, but could be used by non-engineers to change flags.

That's not a feature flag, that's a feature of the product. I would keep the 2 very distinct.

Re: Show HN: Dorkly – Open source feature flags

#48

Post by randerson »

drichelson wrote: post #12
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

The PR is optional, but governance often requires documented peer approval for all production changes. Flag changes can be pushed directly to the main branch with the correct repo permissions. When using the GitHub UI this involves just a little bit of typing and a few clicks. >might as well just change the code at that point If changing the code, running tests, building, and deploying is quicker and less risky then…

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.

Re: Show HN: Dorkly – Open source feature flags

#49

Post by hinkley »

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…

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)

Re: Show HN: Dorkly – Open source feature flags

#50

Post by hinkley »

kkyr wrote: post #39
ryanmcbride wrote: post #35

Earlier quoted context omitted.

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

You're missing the parent's point. It's not about lacking a change control process, but about having the ability to instantly change the state of a flag when necessary. Moreover, these two can coexist effectively.

With Continuous Delivery you should be able to roll back the deployment. If the last change is the only one you need to revert. Of course that stops working when you share the flag system across teams with separate milestones. Your guys are gonna want to flip toggles while my guys are thinking about flipping others.
Post reply on HN