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

181–190 of 232 posts

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

#181

Post by eddd-ddde »

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.

That's why I mention having real stable APIs for cross-service interaction, as you can't guarantee that all teams deploy the exact same commit everywhere at once. It is possible but I'd argue that's beyond what a monorepo provides. You can't exactly atomically update your postgres schema and JavaScript backend in one step, regardless of your repo arrangement.

Adding new APIs is always easy. Removing them not so much since other teams may not want to do a new release just to update to your new API schema.

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

#182

Post by root_axis »

senbrow wrote: post #135
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.

> There is no universally "correct" granularity.

There may not be a universally correct granularity, but that doesn't mean clearly incorrect ones don't exist. 50+ services is almost always too many, except for orgs with hundreds or thousands of engineers.

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

#184

Post by eddd-ddde »

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.

What you really need is stacked changes, where each commit is reviewed, ran on ci, and merged independently.

No information loss, and every commit is valid on their own, so cherry picks maintain the same level of quality.

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

#185

Post by valicord »

mjr00 wrote: post #93
valicord wrote: post #86

Earlier quoted context omitted.

The point is atomic code changes, not atomic deployments. If I want to rename some common library function, it's just a single search and replace operation in a monorepo. How do you do this with multiple repos?

> If I want to rename some common library function, it's just a single search and replace operation in a monorepo. How do you do this with multiple repos? Multiple repos shouldn't depend on a single shared library that needs to be updated in lockstep. If they do, something has gone horribly wrong.

It doesn't need to, it's just much more convenient when you can do everything in a single commit.

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

#186

Post by imiric »

eddd-ddde wrote: post #180
RaftPeople wrote: post #172

Earlier quoted context omitted.

> including "no development branches" Can you explain this comment? Are you saying to develop directly in the main branch? How do you manage the various time scales and complexity scales of changes? Task/project length can vary from hours to years and dependencies can range from single systems to many different systems, internal and external.

Yeah, all new commits are merged to main. The complexity comes from releases. Suppose you have a good commit 123 were all your tests pass for some project, you cut a release, and deploy it. Then development continues until commit 234, but your service is still at 123. Some critical bug is found, and fixed in commit 235. You can't just redeploy at 235 since the in-between may include development of new features that a…

I don't see how you're avoiding development branches. Surely while a change is in development the author doesn't simply push to main. Otherwise concurrent development, and any code review process—assuming you have one—would be too impractical.

So you can say that you have short-lived development branches that are always rebased on main. Along with the release branch and cherry-pick process, the workflow you describe is quite common.

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

#187

Post by imiric »

djhedges wrote: post #67
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.

We use a mono repo and feature flag new features which gives us the deployment control timing.

I can guarantee that your codebase is spaghetti of conditional functionality that no developer understands, and that most of those conditionals are leftovers that are no longer needed, but nobody dares to remove.

Feature flags are a good idea, but they require a lot of discipline and maintenance. In practice, they tend to be overused, and provide more negatives than positives. They're a complement, but certainly not a replacement for VCS branches, especially in monorepos.

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

#188

Post by cadamsdotcom »

codingdave wrote: post #39

> When you ask Claude to "update the pricing page to reflect the new limits," it can... wat. You are running the marketing page from the same repo, yet having an LLM make the updates? You have the data file available. Just read the pricing info from your config file and display it?

Code review still exists, you know.

AI didn’t magically uninvent “let’s have someone else check this over before it’s shipped”.

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

#189

Post by piva00 »

denysvitali wrote: post #64
supermdguy wrote: post #24

How do you guys share types between your frontend and backend? I've looked into tRPC, but don't like having to use their RPC system.

protobuf?

Protobuf is decent enough, I've used Avro and Thrift before (way way before protobuf came to be), and the dev experience of protobuf has been the best so far.

It's definitely not amazing, code generation in general will always have its quirks, but protobuf has some decent guardrails to keep the protocol backwards-forwards compatible (which was painful with Avro without tooling for enforcement), it can be used with JSON as a transport for marshaling if needed/wanted, and is mature enough to have a decent ecosystem of libraries around.

Not that I absolutely love it but it gets the job done.

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

#190

Post by ozozozd »

imiric wrote: post #186
eddd-ddde wrote: post #180

Earlier quoted context omitted.

Yeah, all new commits are merged to main. The complexity comes from releases. Suppose you have a good commit 123 were all your tests pass for some project, you cut a release, and deploy it. Then development continues until commit 234, but your service is still at 123. Some critical bug is found, and fixed in commit 235. You can't just redeploy at 235 since the in-between may include development of new features that a…

I don't see how you're avoiding development branches. Surely while a change is in development the author doesn't simply push to main. Otherwise concurrent development, and any code review process—assuming you have one—would be too impractical. So you can say that you have short-lived development branches that are always rebased on main. Along with the release branch and cherry-pick process, the workflow you describe…

Their dev branch is _the_ development branch.

They don’t do code reviews or any sort of parallel development.

They’re under the impression that “releases are complex and this is how they avoid it” but they just moved the complexity and sacrificed things like parallel work, code reviews, reverts of whole features.

Post reply on HN