Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
It’s really all about using Conway’s Law to your own benefit.
If adding features or fixing bugs consistently requires one person from a fairly small team to make PRs across multiple repos and changes can only really be tested in a staging environment where everything can be tested together, then it’s an anti-pattern.
However, if 100 developers or more are working in a single repo, it’s past time to split it up into appropriate bounded contexts and allow smaller teams to take ownership.
I worked at a place where hundreds of developers worked on a single Rails monolith / monorepo, and enterprise architects insisted that 100,000+ RSpec tests that required PostgreSQL had to run in CI for every PR merge. Every build took 45 minutes and used ungodly amounts of cloud compute. The company ended up building their own custom CI system to reduce their 7 figure CI spend so they could ignore the problem.
You should really not need to do a PR across multiple repos. If you need, you are breaking your code wrong. Some functionality may require multiple PRs, but you should always be able to do those at different moments and test them separately.
The monorepo tools are exactly software that emulate the features of a multi-repo so that you can have thousands of people on the same repository. We also have multi-repo tools that emulate the features of a monorepo, but people don’t hype those online because they are simple and free.
It’s really all about using Conway’s Law to your own benefit.
If adding features or fixing bugs consistently requires one person from a fairly small team to make PRs across multiple repos and changes can only really be tested in a staging environment where everything can be tested together, then it’s an anti-pattern.
However, if 100 developers or more are working in a single repo, it’s past time to split it up into appropriate bounded contexts and allow smaller teams to take ownership.
I worked at a place where hundreds of developers worked on a single Rails monolith / monorepo, and enterprise architects insisted that 100,000+ RSpec tests that required PostgreSQL had to run in CI for every PR merge. Every build took 45 minutes and used ungodly amounts of cloud compute. The company ended up building their own custom CI system to reduce their 7 figure CI spend so they could ignore the problem.
You should really not need to do a PR across multiple repos. If you need, you are breaking your code wrong. Some functionality may require multiple PRs, but you should always be able to do those at different moments and test them separately.
The monorepo tools are exactly software that emulate the features of a multi-repo so that you can have thousands of people on the same repository. We also have multi-repo tools that emulate the features of a monorepo, but people don’t hype those online because they are simple and free.