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

Feature flags in a CI pipeline

andydote.co.uk

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Feature flags in a CI pipeline

#21

Post by verdverm »

Denvercoder9 wrote: post #13
diarrhea wrote: post #5

Earlier quoted context omitted.

Pretty sure the parent meant testing the pipelines themselves, end to end. The tooling around pipelines is awful. A single typo in some variable’s name in a later stage can take minutes to catch. The feedback cycles are very long (cloud machines are much slower than local ones) and IDE tooling is bare-bones. Just give me one large Python file with some library to manage common actions (building up the job DAG, access…

> The feedback cycles are very long (cloud machines are much slower than local ones) and IDE tooling is bare-bones. I'm continuously amazed that none of the major CI providers offer standalone tooling to run and debug your CI pipelines locally. Seems like it'd be a killer feature for anyone working with complex pipelines.

The local & CI parity is one of the main points for https://dagger.io

Re: Feature flags in a CI pipeline

#22

Post by verdverm »

pondidum wrote: post #12
dottedmag wrote: post #6

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.

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.

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?

Re: Feature flags in a CI pipeline

#23

Post by verdverm »

tail_exchange wrote: post #15

I've been thinking about a way to add feature flags to my project's CI pipeline. What makes me afraid of adding such thing is reliability: if someone breaks the feature flag service, now the CI pipeline is broken too. I could just give them a default value if the communication fails, but then we will have builds that are skipping checks potentially due to transient errors. I would be very curious to know the guidance…

An easier solution is to add a json file per branch that holds these "flag" or CI config values. We have a dir `bfg/...` to hold them. Nice thing is they are version controlled and the dev can change values between commits like they do with any other code. This pattern has helped solve a lot of issues and we no longer have complex conditions that key off of branch name patterns.

Re: Feature flags in a CI pipeline

#24

Post by hnbad »

goodoldneon wrote: post #19
hnbad wrote: post #14

Earlier quoted context omitted.

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 o…

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…

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.

Re: Feature flags in a CI pipeline

#26

Post by WorldMaker »

hnbad wrote: post #14
pondidum wrote: post #12

Earlier quoted context omitted.

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.

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 o…

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.)

Re: Feature flags in a CI pipeline

#27

Post by pondidum »

verdverm wrote: post #22
pondidum wrote: post #12

Earlier quoted context omitted.

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.

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?

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.

Re: Feature flags in a CI pipeline

#28

Post by verdverm »

pondidum wrote: post #27
verdverm wrote: post #22

Earlier quoted context omitted.

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?

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.

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?

Post reply on HN