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

131–140 of 232 posts

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

#131

Post by Denvercoder9 »

trevor-e wrote: post #65
Denvercoder9 wrote: post #31

Earlier quoted context omitted.

Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.

Good luck getting 100+ devs to all use the same logical commit style. And if tests fail in CI you get the inevitable "fix tests" commit in the branch, which now spams your main branch more than the meaningful changes. You could rebase the history by hand, but what's the point? You'd have to force push anyway. Squashing is the only practical method of clean history for large orgs.

> Good luck getting 100+ devs to all use the same logical commit style

The Linux kernel manages to do it for 1000+ devs.

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

#132

Post by vasco »

wrs wrote: post #35

This is sort of a whole product , but it’s hardly managing the whole company . Financials? HR? Contracts? Pictures of the last team meeting? It just looks like a normal frontend+backend product monorepo, with the only somewhat unusual inclusion of the marketing folder.

Not even infrastructure as code is in the repository from what one can see.

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

#133

Post by Alconicon »

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…

You always have this problem thats why you have a release process for apis.

And monorepo or not, bad software developers will always run into this issue. Most software will not have 'many teams'. Most software is written by a lot of small companies doing niche things. Big software companies with more than one team, normally have release managers.

My tipp: use architecture unit tests for external facing APIs. If you are a smaller company: 24/7 doesn't has to be the thing, just communicate this to your customers but overall if you run SaaS Software and still don't know how to do zero-downtime-deployment in 2025/2026, just do whatever you are still doing because man come on...

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

#134

Post by dinkleberg »

0xbadcafebee wrote: post #107
Escapade5160 wrote: post #83

This article reads like 4o wrote it. It's so exhausting not being able to find content produced by a human being.

What's exhausting is seeing people complain about AI writing. What exactly are you looking for instead? A poorly written article?

Yes, we're looking for some other human sharing something interesting. There is no requirement to put things out into the world. So when somebody shares something to a discussion board like HN the hope is that if I'm going to spend my time reading it, they spent the time to write it. If I wanted to read an AI response I could just ask it "Tell me about how you could organize an entire business in a monorepo".

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

#135

Post by senbrow »

root_axis wrote: post #88

55 business logic services? Sounds extremely overengineered. I'm sure at least half of those services should be consolidated into others.

There is no universally "correct" granularity.

You could easily scoff the same way about some number of API endpoints, class methods, config options, etc, and it still wouldn't be meaningful without context.

It's ok to split or lump as the team sees fit.

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

#137

Post by yearolinuxdsktp »

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.

And think about what it’s like for humans as well—-spreading a feature over several repos with separate PRs makes either a mockery of the review process (if the PRs have to be merged in one repo to be able to test things together), or significantly increases cognitive overhead of reviewing code.

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

#138

Post by bb88 »

Denvercoder9 wrote: post #31
sallveburrpi wrote: post #26

Earlier quoted context omitted.

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

Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.

At work there was only one way to test a feature, and that was to deploy it to our dev environment. The only way to deploy to dev was to check the repo into a branch, and deploy from that branch.

So one branch had 40x "Deploy to Dev" commits. And those got merged straight into the repo.

They added no information.

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

#139

Post by dheera »

hckr1292 wrote: post #49
dheera wrote: post #22

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

That makes sense when you depend on a shared library. However, if service A depends on endpoint x in service B, then you still have to work out synchronized deployments (or have developers handle this by making multiple separate deployments). To be fair, this problem is not solved at all by monorepos. Basically, only careful use of gRPC (and similar technology) can help solve this… and it doesn’t really solve for app…

> However, if service A depends on endpoint x in service B, then you still have to work out synchronized deployments (or have developers handle this by making multiple separate deployments).

In a polyrepo environment, either:

- B updates their endpoint in a backward compatible fashion, making sure older stuff still works

OR

- B releases a new version of their API at /api/2.0 but keeps /api/1.0 active and working until nothing depends on it anymore, releasing deprecation messages to devs of anyone depending on 1.0

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

#140

Post by cgio »

GeneralMayhem wrote: post #48
lorey wrote: post #30

Earlier quoted context omitted.

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.

Do you take down all of your projects and then bring them back up at the new version? If not, then you have times at which the change is only partially complete.

I would see a potentially more liberal use of atomic, that if the repo state reflects the totality of what I need to get to new version AND return to current one, then I have all I need from a reproducibility perspective. Human actions could be allowed in this, if fully documented. I am not a purist, obviously.
Post reply on HN