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

121–130 of 232 posts

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

#121

Post by William_BB »

mattbillenstein wrote: post #108
trevor-e wrote: post #65

Earlier quoted context omitted.

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.

This - even 5 devs. Also rebasing is just so fraught with potential errors - every month or two, the devs who were rebasing would screw up some feature branch that they had work on they needed and would look to me to fix it for some reason. Such a time sink for so little benefit. I eventually banned rebasing, force pushes, and mandated squash merges to main - and we magically stopped having any of these problems.

We squash, but still rebase. For us, this works quite well. As you said, rebasing needs to be done carefully... But the main history does look nice this way.

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

#122

Post by catlifeonmars »

kccqzy wrote: post #25
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 com…

> This is an organizational issue not a tech issue.

It’s both. Furthermore, you _can_ solve organizational problems with tech. (Personally, I prefer solutions to problems that do not rely strictly on human competence)

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

#124

Post by catlifeonmars »

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.

Seems like a limitation/assumption that is introduced by the tooling (Claude) and could also be improved in the tooling to work equally well with multiple repos.

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

#125

Post by catlifeonmars »

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?

Somehow I suspect this would be a nonissue if it easy to determine whether an article is written by AI or not.

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

#126

Post by scubbo »

catlifeonmars wrote: post #116
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…

> Having all the context for AI in one place is hard to beat though. Seems like a weird workaround, you could just clone multiple repos into a workspace. Agree with all your other points though.

Exactly. Monorepo-enjoyers like to pretend that workspaces don't a) exist, and b) provide >90% of the benefits of a monorepo, with none of the drawbacks.

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

#127

Post by awesome_dude »

sallveburrpi wrote: post #26
giancarlostoro wrote: post #16

Earlier quoted context omitted.

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

Squash loses the commit history - all you end up with is merge merge merge

It's harder to debug as well (this 3000line commit has a change causing the bug... best of luck finding it AND why it was changed that way in the first place.

I, myself, prefer that people tidy up their branches such that their commits are clear on intent, and then rebase into main, with a merge commit at the tip (meaning that you can see the commits AND where the PR began/ended.

git bisect is a tonne easier when you have that

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

#128

Post by Denvercoder9 »

literallyroy wrote: post #96
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.

I’m all ears for a better approach because squashing seems like a good way to preserve only useful information. My history ends up being: - add feature x - linting - add e2e tests - formatting - additional comments for feature - fix broken test (ci caught this) - update README for new feature - linting With a squash it can boil down to just “added feature x” with smaller changes inside the description.

If my change is small enough that it can be treated as one logical unit, that will be reviewed, merged and (hopefully not) reverted as one unit, all these followup commits will be amends into the original commit. There's nothing wrong with small changes containing just one commit; even if the work wasn't written or committed at one time.

Where logical commits (also called atomic commits) really shine is when you're making multiple logically distinct changes that depend on each other. E.g. "convert subsystem A to use api Y instead of deprecated api X", "remove now-unused api X", "implement feature B in api Y", "expose feature B in subsystem A". Now they can be reviewed independently, and if feature B turns out to need more work, the first commits can be merged independently (or if that's discovered after it's already merged, the last commits can be reverted independently).

If after creating (or pushing) this sequence of commits, I need to fix linting/formatting/CI, I'll put the fixes in a fixup commit for the appropriate and meld them using a rebase. Takes about 30s to do manually, and can be automated using tools like git-absorb. However, in reality I don't need to do this often: the breakdown of bigger tasks into logical chunks is something I already do, as it helps me to stay focused, and I add tests and run linting/formatting/etc before I commit.

And yes, more or less the same result can be achieved by creating multiple MRs and using squashing; but usually that's a much worse experience.

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

#129

Post by Escapade5160 »

talos wrote: post #92
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.

Yeah it reads like it, and if a random AI detector (GPTZero) is to be believed it's pretty much all AI generated. Crazy that nobody can be bothered to get rid of the obvious AI-isms "This isn't just for...", "The Challenges (And How We Handle Them)", "One PR. One review. One merge. Everything ships together." It's an immediate signal that whoever wrote this DGAF.

The obvious tell for me is when the article is packed full of 'Its not just x, it's y' statements. I am not sure why LLMs gravitated so heavily towards their current style of writing. Pre LLMs, I can't recall seeing that much written content in that format. If I did, it was in short form content.

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

#130

Post by bb88 »

gorgoiler wrote: post #114
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.

If your monorepo compiles to one binary on one host then fine, but what do you do when one webserver runs vN, another runs v(N-1), and half the DB cluster is stuck on v(N-17)? A monorepo only allows you to reason about the entire product as it should be. The details of how to migrate a live service atomically have little to do with how the codebase migrates atomically.

But isn't that a self-inflicted wound then? I mean is there some reason your devs decided not to fix the DB cluster? Or did management tell you "Eh, we have other things we want to prioritize this month/quarter/year?"

This seems like simply not following the rules with having a monorepo, because the DB Cluster is not running the version in the repo.

Post reply on HN