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

When deployments are easy, code becomes simpler

bitbytebit.substack.com

Post reply on HN
Print view View original

51–60 of 124 posts

Re: When deployments are easy, code becomes simpler

#51

Post by hsn915 »

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…

Is "feature flag as a service" the new trend in backend development?

Why would anyone replace a literal byte in memory with a full program?

Why?

Re: When deployments are easy, code becomes simpler

#52

Post by mrweasel »

mvdtnz wrote: post #37
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.

Then you use etcd or consul.

I would claim that release a new feature by enabling additional code path across multiple apps at once is a bit of an anti-pattern. It seems rather dangerous and error prone. In that case I'd actually release it in reverse order, so to speak. Release the apps that use the services of others first and have it check is this service is available/functional and if not, skip calling it. The release the feature to the next service down the stack. Then you can always rollback the last service and be confident that the callers still work.

It's way more work and I can see why for certain types of application isn't not really worth the trouble.

Re: When deployments are easy, code becomes simpler

#53

Post by QuercusMax »

mrweasel wrote: post #49
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.

One of the very best development teams I worked with had an interesting take, they always did database migrations first. Any new state that was to be added to the system could only be done so by first adding the new database fields or tables. This ensure that version 1 of the code would work with version 1 and 2 of the database. They would then roll out version 2 of the code, but have the new features hidden behind a…

I learned this as standard practice at Google back in 2015.

We got really good at data migrations and it was no big deal - but we only got serious about this after we had a major DB and functionality update that went wrong and took us down for 2 days.

Re: When deployments are easy, code becomes simpler

#54

Post by wingerlang »

ketchupdebugger wrote: post #46

>Much of the time I’m using flags so I can commit unfinished code because I don’t want to create a separate branch and have one source of truth This seems like an incident in the making. If each dev on a team commits unfinished code into prod behind flags, the whole project is going to be littered with flags and unfinished code. Some intern is going to delete a flag or an if check and then everything is going to brea…

I've worked at a large company where everything was under feature flags, think a dozen teams working on apps alone. We didn't push straight to develop, but we definitely had possibly unfinished code on production. For example a feature could be "done" but a bug was found, and the app was already released. That feature flag would simply not be turned on until the next version where it would be fixed.

We had a lot of tests for each feature flag variation, both unit and ui tests.

The codebase wasn't "littered" but there definitely existed unused code under flags, either to-be-used, or to-be-deleted. We had a grafana view of experiments that were old and not yet removed to manage them.

Overall we never had incidents around this, to my knowledge anyway.

Re: When deployments are easy, code becomes simpler

#55

Post by mvdtnz »

mrweasel wrote: post #52
mvdtnz wrote: post #37

Earlier quoted context omitted.

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

Then you use etcd or consul. I would claim that release a new feature by enabling additional code path across multiple apps at once is a bit of an anti-pattern. It seems rather dangerous and error prone. In that case I'd actually release it in reverse order, so to speak. Release the apps that use the services of others first and have it check is this service is available/functional and if not, skip calling it. The re…

The point of feature flags is to decouple releases from deployments.

Re: When deployments are easy, code becomes simpler

#56

Post by mrweasel »

mvdtnz wrote: post #55
mrweasel wrote: post #52

Earlier quoted context omitted.

Then you use etcd or consul. I would claim that release a new feature by enabling additional code path across multiple apps at once is a bit of an anti-pattern. It seems rather dangerous and error prone. In that case I'd actually release it in reverse order, so to speak. Release the apps that use the services of others first and have it check is this service is available/functional and if not, skip calling it. The re…

The point of feature flags is to decouple releases from deployments.

Then you just have a feature flag per app.

Re: When deployments are easy, code becomes simpler

#57

Post by baq »

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.

And useless. Unless customers don’t care about their data.

Re: When deployments are easy, code becomes simpler

#58

Post by brigadier132 »

ketchupdebugger wrote: post #46

>Much of the time I’m using flags so I can commit unfinished code because I don’t want to create a separate branch and have one source of truth This seems like an incident in the making. If each dev on a team commits unfinished code into prod behind flags, the whole project is going to be littered with flags and unfinished code. Some intern is going to delete a flag or an if check and then everything is going to brea…

> This seems like an incident in the making

This is how every major tech company works today.

Re: When deployments are easy, code becomes simpler

#59

Post by calderwoodra »

huac wrote: post #13

I wanted a very simple feature flagging solution, so I wrote my own with Google Sheets as the backend: https://github.com/stillmatic/flagsheet It's slightly more complex than a code push but still very easy to use.

Really nice and simple feature rich solution. Thanks for sharing!

Re: When deployments are easy, code becomes simpler

#60

Post by JimDabell »

mvdtnz wrote: post #37
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.

> Just use a database table" solves for the simplest cases - a single monolithic app.

Most cases are the simplest cases.

No approach works for every single use case, but OP was specifically talking about the common case. You don’t have to shoot for the most complex use case every time.

Post reply on HN