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

Everything as code: How we manage our company in one monorepo

kasava.dev

Post reply on HN
Print view View original

21–30 of 232 posts

Re: Everything as code: How we manage our company in one monorepo

#21

Post by ChadNauseam »

valzam wrote: post #6
emzo wrote: post #3

Earlier quoted context omitted.

Opening Claude from the parent directory is what I do, and it seems to work pretty well, but I do like this monorepo idea so that a single commit can change things in the front end and back end together, since this is a use case that's quite common

Except of course rollout will not be atomic anyway and making changes in a single commit might lead Devs to make changes without thinking about backwards compat

Rollout should be within a minute. Let's say you ship one thing a day and 1/3 things involve a backwards-incompatible api change. That's 1 minute of breakage per 3 days. Aka it's broken 0.02% of the time. Life is too short to worry about such things

Re: Everything as code: How we manage our company in one monorepo

#22

Post by dheera »

The thing I dislike about monorepos is that people don't ship stuff. Multiple versions of numpy and torch exist within the codebase, mitigated by bazel or some other build tool, instead of building binaries and deb packages and shipping actual products with well-documented APIs so that one team never needs to actually touch another team's code to get stuff done.

The people who say polyrepos cause breakage aren't doing it right. When you depend across repos in a polyrepo setup, you should depend on specific versions of things across repos, not the git head. Also, ideally, depend on properly installed binaries, not sources.

Re: Everything as code: How we manage our company in one monorepo

#23

Post by deaux »

giancarlostoro wrote: post #2

I used to be against monorepos... Then I got really into claude code, and monorepo makes sense for the first time in my life, specifically because of tools like Claude. I mean technically I could open all the different repos from the parent directory I suppose, but its much nicer in one spot. Front-end and back-end changes are always in sync this way too. I guess I could work with either option now.

backend-repo $ claude --add-dir ../frontend-repo

Opting for a monorepo because you don't want to alias this flag is.. something you can do, I guess.

Re: Everything as code: How we manage our company in one monorepo

#25

Post by kccqzy »

sethammons wrote: post #17

people talk about "one change, everywhere, all at once." That is a great way to break production on any api change. if you have a db and >2 nodes, you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes. While more obvious with a db schema, it is true for any networked api. At some point, you will have many teams. And one of…

I’m not sure why you made the logical leap from having all code stored in a single repo to updating/deploying code in lockstep. Where you put your code (the repo) can and should be decoupled from how you deploy changes.

> you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes

Of course you design changes to be backwards compatible. Even if you have a single node and have no networked APIs. Because what if you need to rollback?

> Maybe a regression causes something only they use to break. Now the entire org is held hostage by the version needs of one team.

This is an organizational issue not a tech issue. Who gives that one team the power to hold back large changes that benefit the entire org? You need a competent director or lead to say no to this kind of hostage situation. You need defined policies that balance the needs of any individual team versus the entire org. You need to talk and find a mutually accepted middle ground between teams that want new features and teams that want stability and no regressions.

Re: Everything as code: How we manage our company in one monorepo

#26

Post by sallveburrpi »

giancarlostoro wrote: post #16
eddd-ddde wrote: post #10

I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.

I like keeping old branches but a lot of places ditch them, never understood why. I also dislike git squash, it means you have to make a brand new branch for your next PR, waste of time when I should be able to pull down master / dev / main / whatever and merge it into my working branch. I guess this is another reason I prefer the forking approach of github, let devs have their own sandbox and their own branches, and…

squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess

Re: Everything as code: How we manage our company in one monorepo

#27

Post by aylmao »

valzam wrote: post #6
emzo wrote: post #3

Earlier quoted context omitted.

Opening Claude from the parent directory is what I do, and it seems to work pretty well, but I do like this monorepo idea so that a single commit can change things in the front end and back end together, since this is a use case that's quite common

Except of course rollout will not be atomic anyway and making changes in a single commit might lead Devs to make changes without thinking about backwards compat

This is a systems problem that can and should be fixed in the system IMO, not by relying on devs executing processes in some correct order.

Re: Everything as code: How we manage our company in one monorepo

#28

Post by david422 »

ChadNauseam wrote: post #21
valzam wrote: post #6

Earlier quoted context omitted.

Except of course rollout will not be atomic anyway and making changes in a single commit might lead Devs to make changes without thinking about backwards compat

Rollout should be within a minute. Let's say you ship one thing a day and 1/3 things involve a backwards-incompatible api change. That's 1 minute of breakage per 3 days. Aka it's broken 0.02% of the time. Life is too short to worry about such things

> Rollout should be within a minute

And if it's not, it breaks everything. This is an assumption you can't make.

Re: Everything as code: How we manage our company in one monorepo

#29

Post by jvuygbbkuurx »

ChadNauseam wrote: post #21
valzam wrote: post #6

Earlier quoted context omitted.

Except of course rollout will not be atomic anyway and making changes in a single commit might lead Devs to make changes without thinking about backwards compat

Rollout should be within a minute. Let's say you ship one thing a day and 1/3 things involve a backwards-incompatible api change. That's 1 minute of breakage per 3 days. Aka it's broken 0.02% of the time. Life is too short to worry about such things

You might have old clients for several hours, days or forever(mobile). This has to be taken into account, for example by aggressively forcing updates which can be annoying for users, especially if their hardware doesn't support updating.

Re: Everything as code: How we manage our company in one monorepo

#30

Post by lorey »

eddd-ddde wrote: post #10

I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.

Very interesting points. Would you mind sharing a few examples of when cherry-picking is necessary and why atomic changes are a lie?

I'm using a monorepo for my company across 3+ products and so far we're deploying from stable release to stable release without any issues.

Post reply on HN