4 ms·

Indeed, maintaining the greenness of the build in a giant monorepo is extremely expensive. It isn't clear to me that it is worth the investment, even for Googl

• m0zg 7y ago
  It's only expensive if you don't have tests and CI. If you do have tests and CI, it's much cheaper to maintain one repo than three dozen smaller ones: garbage simply can't get into master. Note also, that if you want to ship high quality software, having a fragmented repo doesn't free you from the need to have tests and CI, if anything it leads to duplication of effort.
  • vanniv 7y ago
    I currently live in a monorepo that has pretty good CI and test coverage. That means that I know every time I have work to do because something changed (because the tests go red). That's great. But I still have to do the work every time someone changes anything that affects me
    • m0zg 7y ago
      You're doing it wrong: if _they_ want to change something that affects you, _they_ should be the ones doing the work to not break you. The situations where _you_ have to do anything more than a code review of such changes should be very rare. That's how it works at Google. And besides, it's not like this gets any easier if you have multiple repos. Eventually you have to roll forward your dependencies, and doing the work that goes along with that.
      • vanniv 7y ago
        That's only how it works at Google if the "they" is sufficiently organizationally close that you actually care if you break them (and you'll only even know about it if you're close enough that you run their presubmit)
        • m0zg 7y ago
          No, you don't have to "care". Presubmit _won't let you_ break them. That's the whole point of presubmit - to make sure tip of tree is green 100% of the time. You can't submit something that breaks the build _or_ breaks the tests. You can work with the code owner to make sure you can commit in the first place, but you don't get to just push your changes through and have the code owner deal with the fallout. Facepalm.
• ori_b 7y ago
  So is maintaining the greenness of a fragmented repo. The only difference is when you find out about the breakages.
  • cipherzero 7y ago
    Yes. Thank you! From my experience multi-repo doesn’t make problems go away, it just defers them and introduces others. I’m not against multi-repo or a strong proponent of monorepos... each have their strengths and drawbacks and there is a time and place for either. I struggle to deal with folks who firmly lie in one camp or the other.
    • vanniv 7y ago
      Agreed! Multi-repo makes integrations harder, because you find out about breakages later -- which means that it might be harder to identify the cause and more likely that someone depends on the behavior that broke you by the time you notice it. But, multi-repo makes local development faster and cheaper -- you're insulated from the churn of everybody else's check-ins. You don't have to constantly refactor everything every time some dependency makes a minor tweak. You get more done and have a smoother development lifecycle -- but you're going to keep falling behind your dependencies unless you invest in keeping up -- and that part of the process is more unfun the less often you do it. I currently live in a monorepo. I don't love it. But I've also not loved the multi-repos I've lived in, so... shrug