Everything as code: How we manage our company in one monorepo • Hacker News Board

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

#221

Post by eddd-ddde » Fri, Jan 02, 2026, 7:33 PM UTC

RaftPeople wrote: post #219

eddd-ddde wrote: post #217

Earlier quoted context omitted.

It depends a lot on a team by team basis as different teams would like different approaches In general, all new code gets added to the tip of main, your only development branch. Then, new features can also be behind feature flags optionally. This allows developers to test and develop on the latest commit. They can enable a flag if they are interested in a particular feature. Ideally new code also comes with relevant…

> As another example, a more complex service may require more testing. You do the same first steps, grab commit 123, test, build, but now deploy to staging. At this point staging will be fixed to commit 123, even as development continues. A QA team can perform heavy testing, fixes are made to main and cherry picked, or the release dropped if something is very wrong. At some point the release is verified and you just…

It totally depends on how you want to test releases. You can have nightlies that deploy the latest green commit every day, do some QA there, then once it is feature complete promote it to a stable release that only cherry picks fixes, then finally promote it to production.

It will be highly dependent on the kind of software you are building. My team in particular deals with a project that cuts "feature complete" releases every 6 months or so, at that point only fixes are allowed for another month or so before launch, during this time feature development continues on main. Another project we have is not production critical, we only do automated nightlies and that's it.

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

#222

Post by RaftPeople » Fri, Jan 02, 2026, 8:42 PM UTC

eddd-ddde wrote: post #221

RaftPeople wrote: post #219

Earlier quoted context omitted.

> As another example, a more complex service may require more testing. You do the same first steps, grab commit 123, test, build, but now deploy to staging. At this point staging will be fixed to commit 123, even as development continues. A QA team can perform heavy testing, fixes are made to main and cherry picked, or the release dropped if something is very wrong. At some point the release is verified and you just…

It totally depends on how you want to test releases. You can have nightlies that deploy the latest green commit every day, do some QA there, then once it is feature complete promote it to a stable release that only cherry picks fixes, then finally promote it to production. It will be highly dependent on the kind of software you are building. My team in particular deals with a project that cuts "feature complete" rele…

> It totally depends on how you want to test releases.

For a big project, typically it involves deploying to a fully functioning QA environment so all functionality can be tested end to end, including interactions with all other systems internal to the enterprise and external. Eventually user acceptance testing and finally user training before going live.

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

#223

Post by array_key_first » Fri, Jan 02, 2026, 11:34 PM UTC

yencabulator wrote: post #220

array_key_first wrote: post #205

Earlier quoted context omitted.

If you have a monolith you get atomic deployment, too.

You lose atomic deployment and have a distributed system the moment you ship Javascript to a browser. Hell, you lose "atomic" assets the moment you serve HTML that has URLs in it. Consider switching from to . If you for example, delete kitty from the server and upload puppy.jpg, then change html, you can have a client with URL to kitty while kitty is already gone. Generally anything you published needs to stay alive…

They just refresh the page, it's not a big deal. It'll happen on form submission or any navigation anyway. Some people might be caught in a weird invalid state for, like, a couple minutes absolute maximum.

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

#224

Post by yencabulator » Fri, Jan 02, 2026, 11:38 PM UTC

array_key_first wrote: post #223

yencabulator wrote: post #220

Earlier quoted context omitted.

You lose atomic deployment and have a distributed system the moment you ship Javascript to a browser. Hell, you lose "atomic" assets the moment you serve HTML that has URLs in it. Consider switching from to . If you for example, delete kitty from the server and upload puppy.jpg, then change html, you can have a client with URL to kitty while kitty is already gone. Generally anything you published needs to stay alive…

They just refresh the page, it's not a big deal. It'll happen on form submission or any navigation anyway. Some people might be caught in a weird invalid state for, like, a couple minutes absolute maximum.

If you're not interested in solving the problem, then don't claim to solve the problem.

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

#225

Post by fragmede » Sat, Jan 03, 2026, 12:43 AM UTC

NeutralWanted wrote: post #167

codegeek wrote: post #38

I have a question about Monorepo. Do companies really expose their entire source code all in one repo for their devs to download ? I understand that people can always do bad things if they want but with monorepo, you are literally letting me download everything right ?

I work at Google, and yes. We use a monorepo for absolutely everything you can think of. But good luck getting that code off a corp device without being caught!

Android never fully made it into google3. Google is big and does so much stuff and almost everything is in there but there are exceptions!

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

#226

Post by deaux » Sat, Jan 03, 2026, 2:35 AM UTC

odie5533 wrote: post #73

deaux wrote: post #23

Earlier quoted context omitted.

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.

What does the flag do? Just allow Claude to access that directory?

Adds it as a working directory, yes. So pretty much the same effect that they were trying to achieve with the monorepo.

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

#227

Post by nkmnz » Sat, Jan 03, 2026, 8:25 AM UTC

Denvercoder9 wrote: post #166

nkmnz wrote: post #157

Earlier quoted context omitted.

Why that? In a very simple case, all services of a monorepo run on a single VM. Spin up new VM, deploy new code, verify, switch routing. Obviously, this doesn't work with humongous systems, but the idea can be expanded upon: make sure that components only communicate with compatible versions of other components. And don't break the database schema in a backward-incompatible way.

So yes, in theory you can always deploys sets of compatible services, but it's not really workable in practice: you either need to deploy the world on every change, or you need to have complicated logic to determine which services are compatible with which deployment sets of other services. There's a bigger problem though: in practice there's almost always a client that you don't control, and can't switch along with…

The notion of external clients is a smell. If that’s the case, you need a compat layer between that client and your entrypoints, otherwise you’ll have a very hard time evolving anything. In practice, this can include providing frontend assets under previously cached endpoints; a version endpoint that triggers cache busting; a load balancer routing to a legacy version for a grace period… sadly, there‘s no free lunch here.

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

#228

Post by array_key_first » Sat, Jan 03, 2026, 10:29 PM UTC

yencabulator wrote: post #224

array_key_first wrote: post #223

Earlier quoted context omitted.

They just refresh the page, it's not a big deal. It'll happen on form submission or any navigation anyway. Some people might be caught in a weird invalid state for, like, a couple minutes absolute maximum.

If you're not interested in solving the problem, then don't claim to solve the problem.

Right, there's level of solutions. You can't sit here and say that a few seconds of invalid state on the front-end only for mayyyyybe .01% of your users is enough to justify a sprawling distributed system because "well deployments aren't atomic anyway!1!".

IMO, monorepos are much easier to handle. Monoliths are also easier to handle. A monorepo monolith is pretty much as good as it gets for a web application. Doing anything else will only make your life harder, for benefits that are so small and so rare that nobody cares.

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

#229

Post by yencabulator » Sat, Jan 03, 2026, 10:54 PM UTC

array_key_first wrote: post #228

yencabulator wrote: post #224

Earlier quoted context omitted.

If you're not interested in solving the problem, then don't claim to solve the problem.

Right, there's level of solutions. You can't sit here and say that a few seconds of invalid state on the front-end only for mayyyyybe .01% of your users is enough to justify a sprawling distributed system because "well deployments aren't atomic anyway!1!". IMO, monorepos are much easier to handle. Monoliths are also easier to handle. A monorepo monolith is pretty much as good as it gets for a web application. Doing a…

Monorepo vs not is not the relevant criteria. The difference is simply whether you plan your rollout to have no(/minimal) downtime, or not. Consider SQL schema migration to add a non-NULL column on a system that does continuous inserts.

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

#230

Post by array_key_first » Mon, Jan 05, 2026, 8:43 PM UTC

yencabulator wrote: post #229

array_key_first wrote: post #228

Earlier quoted context omitted.

Right, there's level of solutions. You can't sit here and say that a few seconds of invalid state on the front-end only for mayyyyybe .01% of your users is enough to justify a sprawling distributed system because "well deployments aren't atomic anyway!1!". IMO, monorepos are much easier to handle. Monoliths are also easier to handle. A monorepo monolith is pretty much as good as it gets for a web application. Doing a…

Monorepo vs not is not the relevant criteria. The difference is simply whether you plan your rollout to have no(/minimal) downtime, or not. Consider SQL schema migration to add a non-NULL column on a system that does continuous inserts.

Again, that's trivial if you use up and down servers. No downtime, and to your users, instant deployment across the entire application.

If you have a bajillion services and they're all doing their own thing with their own DB and you have to reconcile version across all of them and you don't have active/passive deployments, yes that will be a huge pain in the ass.

So just don't do that. There, problem solved. People need to stop doing micro services or even medium sized services. Make it one big ole monolith, maybe 2 monoliths for long running tasks.