Monorepos: Please don’t

Post by titanomachy » Mon, Jan 07, 2019, 4:16 AM UTC

ashelmire wrote: post #368

joshuamorton wrote: post #311

Earlier quoted context omitted.

At Google scale, you'd either need tooling for automated version bumps, or some other infra to manage versioning. You'd need cross repo bisection. You'd need a way to run all tests in all repos reflecting a new change. There's 10s or hundreds more frs I could list.

“You'd need a way to run all tests in all repos reflecting a new change.” You really shouldn’t have to run every test on every product. Or really any other repos. Use semantic versioning, pin your dependencies, don’t make breaking changes on patch or minor versions.

When you change a project, you have to test the effect of your changes on downstream dependencies. Semver is wishful tthinking. Even a change that _you_ think is non-breaking could break something. Saying "well the downstream team was using undocumented behaviour so it's their fault" doesn't really hold much water when your team is Driving Directions and the downstream team is Google Maps Frontend and your change caused a production outage.

Post by wildengineer » Mon, Jan 07, 2019, 8:20 PM UTC

thanatos_dem wrote: post #289

yowlingcat wrote: post #256

I think this article is complete horseshit. A monorepo will serve you 99% of the time until you hit a certain level of scale when you get to worry about whether a monorepo or a polyrepo is actually material. Most cases are never going to get there. Before that point, a polyrepo is purely a distraction and makes synchronous deployment really painful. We had to migrate a polyrepo to a monorepo and it was not fun becaus…

I work on CI/CD systems, and that’s one thing that definitely gets harder in a monorepo. So you made a commit. What artifacts change as a result? What do you need to rebuild, retest, and redeploy? It doesn’t take a large amount of scale to make rebuilding and retesting everything impossible. In a poly repo world, the repository is generally the unit of building and deployment. In monorepo it gets more messy. For inst…

In the java world this gets solved with gradle's incremental build system, which uses a build cache, a user configured dependency tree, and some hashing to determine what needs to build.

Re: Monorepos: Please don’t

Re: Monorepos: Please don’t