We’re considering this at my org. We’ve got a distributed backend with about 2 dozen repos, with a big web of dependencies between them.
When you need to make a breaking change to one that is depended on by a lot of the other repos, it can be incredibly tedious to fix all the downstream effects.
Using trunk would resolve it, but would also of course introduce other issues.
Multi-repo software products maintained by the same team are another thing I'm probably never going to understand. In reality the components are never fully decoupled and nearly always released together.
When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components and tested again.
With multi-repository it's much harder to isolate a change over multiple components into one PR and test those changes together. Instead they develop separately and after some time many of those changes are tested together. It's just making the feedback loop longer without any added value.
> When splitting up a product into multiple repositories a lot of new problems are created. Every sub-project needs to be testable completely independently and then in a later stage integrated with the other components and tested again.
While I'm a fan of monorepos, that issue doesn't completely disappear there, does it? I mean, if the monorepo contains the code for N artifacts (say, N, microservices that interact with one another), you will still have to make sure that the master version of microservice 1 plays nicely with the currently deployed version of microservice 2.
I think this kind of complexity is not the reality of most developers. They just stop all old services, update them and re-start them during a maintenance window.
That'd be news to me. At least in all big companies that I've come across, where revenue depends on services to be available 24/7 and maintenance windows maybe happen once a year, I have never heard of such a thing.
When you need to make a breaking change to one that is depended on by a lot of the other repos, it can be incredibly tedious to fix all the downstream effects.
Using trunk would resolve it, but would also of course introduce other issues.