3 ms·

You seem to mix two different goals here. Atomic commits across everything surely is a feature of a monorepo which a manyrepo setup cannot replicate. However, t

by qznc 5y ago

You seem to mix two different goals here. Atomic commits across everything surely is a feature of a monorepo which a manyrepo setup cannot replicate. However, the "test whole company's code" could also be achieve with a central package manager and many repos. That is what Amazon does: http://beza1e1.tuxen.de/amazon_manyrepo_builds.html http://beza1e1.tuxen.de/amazon_manyrepo_builds.html

majormajor 5y ago
Yeah, there's two different aspects in there (though without the full-blown testing making broad atomic commits isn't super attractive to me anyway. ;) ) Amazon's Brazil system doesn't sound like it does the "test the whole company's code" aspect in the same way. > If you create a package at Amazon, you specify an interface version like "1.1". As long as changes are backwards-compatible, the interface version is not changed. When Brazil builds a package, it appends an additional number to turn it into a build version like "1.1.3847523". You can only specify dependencies on interface versions. So if I'm working on a non-backwards-compatible version, my users aren't going to pull it down immediately in the build (if I properly call it version 1.2.x), so the build won't show which of them it broke. Even if you depend on the latest version instead of pinning to a major version, how would I force a company-wide build of everything that depended on me using my not-yet-landed branch? I can run those tests in a monorepo on my branch directly, I don't see how I'd do it in a manyrepo setup without a very specific set of "every project in the company specifies its dependencies as depending on specific, easily-overrideable, commit SHA versions."
- grogenaut 5y ago
  Actually to do that, one was is to just make 1.1 as 1.0 in a test branch to do the test build and build it against everything. There are other ways to do this as well, depends on what you're doing. But it's important to note amazon doesn't monorepo like you are used to thinking, so it is actually on everyone to take the updates on the schedule they've set via automation or if it's an emergency via ticketing / policy. You are merely seeing if it's going to work, the automation does the rest, possibly over weeks. And I am simplifying things here to make it easier to understand. Understanding brazil from not using it, is about as difficult as understanding git rebase coming from CVS, eg there are concepts you didn't even knew existed that you have to understand how to use to operate at large scale.

by qznc 5y ago

majormajor 5y ago

Yeah, there's two different aspects in there (though without the full-blown testing making broad atomic commits isn't super attractive to me anyway. ;) ) Amazon's Brazil system doesn't sound like it does the "test the whole company's code" aspect in the same way. > If you create a package at Amazon, you specify an interface version like "1.1". As long as changes are backwards-compatible, the interface version is not changed. When Brazil builds a package, it appends an additional number to turn it into a build version like "1.1.3847523". You can only specify dependencies on interface versions. So if I'm working on a non-backwards-compatible version, my users aren't going to pull it down immediately in the build (if I properly call it version 1.2.x), so the build won't show which of them it broke. Even if you depend on the latest version instead of pinning to a major version, how would I force a company-wide build of everything that depended on me using my not-yet-landed branch? I can run those tests in a monorepo on my branch directly, I don't see how I'd do it in a manyrepo setup without a very specific set of "every project in the company specifies its dependencies as depending on specific, easily-overrideable, commit SHA versions."

grogenaut 5y ago
Actually to do that, one was is to just make 1.1 as 1.0 in a test branch to do the test build and build it against everything. There are other ways to do this as well, depends on what you're doing. But it's important to note amazon doesn't monorepo like you are used to thinking, so it is actually on everyone to take the updates on the schedule they've set via automation or if it's an emergency via ticketing / policy. You are merely seeing if it's going to work, the automation does the rest, possibly over weeks. And I am simplifying things here to make it easier to understand. Understanding brazil from not using it, is about as difficult as understanding git rebase coming from CVS, eg there are concepts you didn't even knew existed that you have to understand how to use to operate at large scale.