4 ms·
It’s a nightmare only if you think of the monorepo as just throwing everything in one place (aka just a technical choice). A monorepo requires org changes. It
by jmmv 3y ago
It’s a nightmare only if you think of the monorepo as just throwing everything in one place (aka just a technical choice).
A monorepo requires org changes. It requires staffing teams to handle processes and tooling for everyone else. (And it may require something else than git… but git will work OK for reasonably large ones anyway.)
I wrote about some of this here: https://jmmv.dev/2023/08/costs-exposed-monorepo-multirepo.html https://jmmv.dev/2023/08/costs-exposed-monorepo-multirepo.ht...
- mhh__ 3y agoFWIW "Monorepo requires people to work on it" is organisationally a bit of a cop out because everything requires this kind of work, its just a difference between each team dedicating some time to it in there little bubble (in which they do things slightly differently) versus doing it once at a larger scale centrally - this requires some investment in the form of salary but you would still spend this money in the first place, you just don't notice. Boiling frogs and all that. You'd also be surprised just how little work this actually is if you get it right, versus having to fix 50 different hacked up solutions across your company. It does put strain onto some tooling, but these days git seems to be fine well beyond kernel-scale - when you are this size you have "made it" anyway.