4 ms·

I sense that Google invests much more in it's infrastructure then most companies make in revenue. I've worked with monorepos, and I'd be loathe to recommend it

I sense that Google invests much more in it's infrastructure then most companies make in revenue. I've worked with monorepos, and I'd be loathe to recommend it as well; the combination of culture shift and tooling it takes to keep a monorepo system running makes most CD processes you see today look like child's play. There is a lot of very good free software that supports most of the open source approach to CD these days; but very, very little freely available monorepo tooling. Just check out https://github.com/korfuri/awesome-monorepo https://github.com/korfuri/awesome-monorepo - it's a quick read. I haven't found many other notably superior compilations. Compared with available OSS workflows and tooling, it's rather sparse, filled with bespoke approaches everywhere.

ryancox 8y ago
Agreed about the lack of monorepo tooling. There's just not that much out there. A couple of other links I didn't see in the awesome-monorepo: - https://github.com/facebookexperimental/mononoke https://github.com/facebookexperimental/mononoke - I hear this is a real thing and not a science fair project - https://github.com/bors-ng/bors-ng https://github.com/bors-ng/bors-ng - Needed in a monorepo to handle high arrival rate of commits / merges
golangnews 8y ago
What problems specifically did you see? Was this because the repo was too large? I understand at google scale you'd need lots of tooling but why at a smaller scslr of merging a dozen small repos?
- mr_tristan 8y ago
  The biggest problems are always cultural. Most monorepo workflows really reinforce constant integration, and once you have separate teams with separate managers, I've always witnessed constant conflict that ended up trying to establish spheres of control. It's bizarre - but it's something I've seen at pretty much every place I've worked at. With all that integration, your single CI toolchain is front and center since everyone's success or failure is tied to it. While projects like bazel exist, how many developers do you know work with bazel every day? I no nobody who does. And most want documented IDE support and ease of use, not some optimal CI workflow. I've found gradle to be OK, but even that kind of pushes everyone toward using Jetbrains tooling. In the end, almost real monorepos have significant custom CI tooling that wires together different toolchains, and, they may have to maintain custom tooling for use in developer machines. And that custom tooling can get expensive to maintain as the project scales up.
  - golangnews 8y ago
    Thanks

ryancox 8y ago

Agreed about the lack of monorepo tooling. There's just not that much out there. A couple of other links I didn't see in the awesome-monorepo: - https://github.com/facebookexperimental/mononoke https://github.com/facebookexperimental/mononoke - I hear this is a real thing and not a science fair project - https://github.com/bors-ng/bors-ng https://github.com/bors-ng/bors-ng - Needed in a monorepo to handle high arrival rate of commits / merges

golangnews 8y ago

What problems specifically did you see? Was this because the repo was too large? I understand at google scale you'd need lots of tooling but why at a smaller scslr of merging a dozen small repos?

mr_tristan 8y ago
The biggest problems are always cultural. Most monorepo workflows really reinforce constant integration, and once you have separate teams with separate managers, I've always witnessed constant conflict that ended up trying to establish spheres of control. It's bizarre - but it's something I've seen at pretty much every place I've worked at. With all that integration, your single CI toolchain is front and center since everyone's success or failure is tied to it. While projects like bazel exist, how many developers do you know work with bazel every day? I no nobody who does. And most want documented IDE support and ease of use, not some optimal CI workflow. I've found gradle to be OK, but even that kind of pushes everyone toward using Jetbrains tooling. In the end, almost real monorepos have significant custom CI tooling that wires together different toolchains, and, they may have to maintain custom tooling for use in developer machines. And that custom tooling can get expensive to maintain as the project scales up.
- golangnews 8y ago
  Thanks