[criley2]

Or you have a monorepo and you make the change in your backend, then you make the change in your dependencies, then you have one commit, one PR, one test run, and one release.

The solutions to monorepo taking 10x longer to build seem to be "Spend 10x longer on the manual developer parts doing 10x more procedure with more tools, more rules, more work"

[pojzon]

Sounds good, doesnt work.

One place change == X possible conflicts.

Ten places over longer period of time (a lot bigger PR) == XXX possible conflicts.

All depends on the size of the team and project.

Tho its hard to find a good place to switch from one approach to the other one.

[criley2]

You assert that it doesn't work however we are in a thread where a major company like Uber has switched to it making your assertion ring hollow.

I do not understand your point about conflicts as 3 commits across 3 projects with 3 different CI pathways is going to cause more conflicts than 1 commit across 1 repo. In my experience managing one code change or project across 3 repos is a 10X difficulty increaser in terms of repo management, conflicts, etc. It's not just 3X harder, it's 10X harder to me. The number of times I've seen a spelling mistake/naming difference/etc in 1 out of 3 repos because the PRs were done separately and no one noticed is too damn high.

The simplicity of having it all together strongly outweighs the benefits of multi repo in most situations IMO. The number of projects/companies/etc that would benefit from some highly engineered microservice-based multi-repo monster is probably less than 100 in my country, and 1000 worldwide.

[pojzon]

The issue is pretty simple. If you have 100 ppl working on the same directory, the chance of them conflicting each other is ALOT BIGGER than 100 ppl working on 10 different directories. It's a simple probability.

This is the issue with monorepos -> That over time the more ppl work on them, the higher the chance of the CICD to fail due to conflicts. And till now pretty much NOONE in the world fully resolved the conflicts issue.

Companies introduce merge queues which cripple productivity, because every next merge "can" (but doesn't have to) break all previous PRs.

Instead of having a very easy Feature-Branch pipeline, you have to build some abomination that becomes a bottleneck as soon as the company starts growing.

--- Like I said in other comment - majority of IT still lives in GitFlow/EnvFlow hell. Some of us learnt from those mistakes and do better now.