When deployments are easy, code becomes simpler • Hacker News Board

Re: When deployments are easy, code becomes simpler

#31

Post by chaxor » Wed, Sep 06, 2023, 2:25 AM UTC

ljm wrote: post #24

dmoy wrote: post #2

> Is this bad because I now have to do a deployment to enable the feature? ... I would argue as long as your deployments are easy, this is the better way to do things because it reduces the complexity of integrating with a third-party tool. Shoot, even when it's all first party tooling, I prefer a release-flags-and-binary as an atomic unit. If the flags and binary are going out as a single push, it simplifies a lot o…

The problem is when your deployment depends on external state like a database. Code rollbacks are trivial, rolling back state (if you even can) is not.

If a git commit hash was directly tied to a data hash at that state (IPFS), that would be trivial.

Re: When deployments are easy, code becomes simpler

#32

Post by daigoba66 » Wed, Sep 06, 2023, 2:26 AM UTC

As an aside, those “feature flags as a service” tools have some neat features, but are just way too expensive for what most apps probably need: simple binary flags that can change at runtime.

Example: just use a database table. Query and cache in memory for 60s. If you want, build a simple internal web page or tool to toggle flags. This works, and scales (from experience).

Do many apps really need A/B testing or segmented rollout? Maybe, but probably not.

Re: When deployments are easy, code becomes simpler

#33

Post by dmoy » Wed, Sep 06, 2023, 2:34 AM UTC

ljm wrote: post #24

dmoy wrote: post #2

> Is this bad because I now have to do a deployment to enable the feature? ... I would argue as long as your deployments are easy, this is the better way to do things because it reduces the complexity of integrating with a third-party tool. Shoot, even when it's all first party tooling, I prefer a release-flags-and-binary as an atomic unit. If the flags and binary are going out as a single push, it simplifies a lot o…

The problem is when your deployment depends on external state like a database. Code rollbacks are trivial, rolling back state (if you even can) is not.

Sure, that is still a problem. But that problem exists whether or not your flags/configs are pushed atomically with your code/binary changes.

Having flags push separately adds another problem on top of data corruption.

Re: When deployments are easy, code becomes simpler

#34

Post by jcrben » Wed, Sep 06, 2023, 2:40 AM UTC

hinkley wrote: post #20

GrinningFool wrote: post #12

Earlier quoted context omitted.

You're in a for a long tail of pain if you have significant uptake. To avoid this, you will need have a clear policy on what you're willing to support (eg versions up to 1 year old, or "major version - 1", etc.), and stick to it. Otherwise, people will expect you to support all of it, forever.

Bug fix releases never get deployed. If you want people to keep up to date with your releases, you either have to provide an automatic update facility that they have to manually turn off (ugh, too hard), or you have to dangle desirable features as carrots in front of them, so that upgrading is exciting instead of a social obligation.

My experience is kinda the opposite. Big companies get into certain workflows and don't want to change, altho they are happy to take bugfixes. This is also where I'm at with much of the software I rely upon, some of which I pull at my own whim.

Re: When deployments are easy, code becomes simpler

#35

Post by samtho » Wed, Sep 06, 2023, 2:44 AM UTC

daigoba66 wrote: post #32

As an aside, those “feature flags as a service” tools have some neat features, but are just way too expensive for what most apps probably need: simple binary flags that can change at runtime. Example: just use a database table. Query and cache in memory for 60s. If you want, build a simple internal web page or tool to toggle flags. This works, and scales (from experience). Do many apps really need A/B testing or segm…

This technique has been used since Wordpress days and earlier. At it’s core, it’s a “meta” table with a string identifier and some value. It’s a pattern I still use today in my own web apps.

Re: When deployments are easy, code becomes simpler

#36

Post by mvdtnz » Wed, Sep 06, 2023, 2:59 AM UTC

rvrs wrote: post #18

mvdtnz wrote: post #17

Earlier quoted context omitted.

I'd rather have unfinished feature flagged code in master (and therefore production) than have the same unfinished code withering in a long running branch, diverging from master and causing integration problems later. > Either finish your work or delete the unneeded code. It's work in progress. We're working on getting it finished.

>It's work in progress. We're working on getting it finished. So finish it and then I will merge your PR ;) What's the use of putting it in master if it's not finished? It's the author's responsibility to get it merged successfully. If they're taking too long and have to rebase and re-work their code to integrate, that's on them. Pushing it into master is either wasting a reader's time (per the original comment) or,…

> So finish it and then I will merge your PR ;) What's the use of putting it in master if it's not finished?

Because of the thing I said in the sentence before the one you quoted.

> If they're taking too long and have to rebase and re-work their code to integrate, that's on them.

No, in the organisations I build, we work as a team and if someone is taking too long it's because we don't have the systems in place to help them work faster. There is very clear research on the benefits of working in small batches and integrating continuously. If that research has passed you by then I strongly suggest you go back and take a look.

Re: When deployments are easy, code becomes simpler

#37

Post by mvdtnz » Wed, Sep 06, 2023, 3:05 AM UTC

daigoba66 wrote: post #32

As an aside, those “feature flags as a service” tools have some neat features, but are just way too expensive for what most apps probably need: simple binary flags that can change at runtime. Example: just use a database table. Query and cache in memory for 60s. If you want, build a simple internal web page or tool to toggle flags. This works, and scales (from experience). Do many apps really need A/B testing or segm…

"Just use a database table" solves for the simplest cases - a single monolithic app. It works incredibly well in this case. It falls apart when I need to turn features on across multiple apps together.

Re: When deployments are easy, code becomes simpler

#38

Post by totallywrong » Wed, Sep 06, 2023, 3:06 AM UTC

TIL there's an industry around feature flags. I can see how it can be useful, but imo if you're doing the modern approach with k8s, gitops, etc. deployments are too easy to bother with this.

Re: When deployments are easy, code becomes simpler

#39

Post by ehnto » Wed, Sep 06, 2023, 3:11 AM UTC

daigoba66 wrote: post #32

As an aside, those “feature flags as a service” tools have some neat features, but are just way too expensive for what most apps probably need: simple binary flags that can change at runtime. Example: just use a database table. Query and cache in memory for 60s. If you want, build a simple internal web page or tool to toggle flags. This works, and scales (from experience). Do many apps really need A/B testing or segm…

I think most frameworks I have worked with have the concept of configurations, more advanced ones have config that can be overriden by environment files. Definitely a solved problem if you want to roll your own.

.env files are the quick and dirty version for simple sites that don't have an admin panel or database.

Re: When deployments are easy, code becomes simpler

#40

Post by tbrownaw » Wed, Sep 06, 2023, 3:16 AM UTC

chaxor wrote: post #31

ljm wrote: post #24

Earlier quoted context omitted.

The problem is when your deployment depends on external state like a database. Code rollbacks are trivial, rolling back state (if you even can) is not.

If a git commit hash was directly tied to a data hash at that state (IPFS), that would be trivial.

Or have the SAN make a snapshot of your db before the deploy, no fancy solution-looking-for-a-problem tech needed.

Completely reverting all the state to some point in the past is easy and have been a solved problem for quite a while.

The actual problem is undoing states changes related to the code change, while not losing state changes related to normal system activity.

If I add some new fields to how my web forum records posts, and then find out that it's eating every tenth post and need to revert, it'd be good to not lose and posts made in the meantime.