[dottedmag]

It looks like an additional tool and a new remote service to talk to. Are there any CIs that don't support editable variables on scopes larger than a build?

The article talks about GH Actions, they have org/repo/env variables.

Even Jenkins has variables usable from the build.

[pondidum]

Sure you can use the environment variables, and if you have simple uses cases this is probably the best way to go.

In this case, we're using LaunchDarkly's targeting to serve different variations to groups of users, and also using the in built monitoring LaunchDarkly provides to see how often each is requested etc.

[hnbad]

It makes sense if you already use a service like LaunchDarkly but adding a whole new service like LaunchDarkly to your stack seems overkill for most people using feature flags. It took me a long time to understand how to work with feature flags in projects that don't require all the monitoring and overhead these services provide because all videos and articles I could find on the subject always framed them in terms of using a service like that.

At the end of the day, a feature flag is just a boolean variable determined at run time that can be used to switch code paths on or off. For most purposes that can be as simple as having a list of strings on your user model and checking if it contains a specific value. Adding a service can be valuable if you need to be able to manage those flags more intelligently or monitor them or want to do more structured A/B testing or whatever, but always tying the concept to a commercial service just obfuscates what it actually is and does.

[WorldMaker]

Yes, the somewhat unfavorable view of LaunchDarkly is that it is If-Condition-As-A-Service. (They add a lot more value than just that, of course. Just that's the raw nutshell of what they do.)

I have had too many conversations complicated by the fact that when I say off hand "well just use a feature flag for that" or "maybe you should wrap that in a feature flag" they picture massive abstractions and infrastructure and often what I mean is simply "add a configurable variable somewhere, the environment or the user table in a database or a JSON file or something else, then add boring if statements checking that flag". Sometimes it is okay to just start with the basics.

(Again, not to disparage LaunchDarkly. Having "proper" infrastructure for it can provide a lot of nice-to-haves and there are definite benefits to the tools that they value add. Just that sometimes the marketing of tools like that does come at the cost of over-complicating the discussion of the basics of the thing.)

[goodoldneon]

Bespoke feature flag systems can become a quagmire. You might think “we only need a boolean value”, but then you need a number, and then you need a string, and then you need a UI to manage it, and then you have a 2nd service and DB and have to expose feature flags via an API endpoint, and then you realize that getting feature flag values via HTTP calls is causing latency and reliability issues, and then and then and then.

I worked at a company that went far down that slippery slope and now there’s and horribly convoluted bespoke feature flag system that no one enjoys using and no one wants to maintain.

I’ve used LaunchDarkly and it’s really nice. The only downsides I’ve experienced are:

- UI is complicated.

- They have the concept of end users but not end “organizations” (like “set this flag to X for an entire customer organization”). There are hacky ways to do this but they feel icky.

[hnbad]

Sure but by that logic you can outsource any component of your software from the start because it might evolve to be something more complex.

For contrast, adding another service that comes anywhere near touching user data (including user IDs or IP addresses) means doing due dilligence on another service provider, signing a data processing agreement with them, vetting their data protection claims, updating your privacy policy, adjusting your processes for users' data requests (including export, change and removal of their PII) and so on, not to mention adding another recurring expense, point of failure and third-party API dependency.

TINSTAAFL. Of course I understand for many companies (especially outside the EU) a service like this may be much closer to "free" because most companies try to get away with not doing even half of the things I described, whether or not that will come back to bite them. Especially if you're in the business of running a VC-backed startup designed for growth it's often a safer bet to ignore that your engine is on fire as long as you continue to go fast because if you can hit your target (i.e. "exit", whether via acquisition, acquihire or going public) in time that will be someone else's problem or no longer matter.

[verdverm]

How do you handle flag changes in the middle of builds, where the flag is being checked in multiple places and the flip happens between them?

[pondidum]

Only read the flag once! For multiple flags we tend to have the first step in the build read all flags we care about and export them to environment variables.

[verdverm]

How do you enforce that they are only read upfront?

Why not just make them parameters if you are going to put them upfront and turn them into ENVs?

How do you deal with a commit that needs to be rerun? What if the flags have changed in between?