3 ms·
Correct. We measured how long it took to integrate changes in the core libraries into the consumers (multiple PRs) versus doing it on a monorepo (single PR for
by ratww 5y ago
Correct. We measured how long it took to integrate changes in the core libraries into the consumers (multiple PRs) versus doing it on a monorepo (single PR for change). We ran them together for a couple weeks and the difference was big.
The biggest differences were in changes that would break the consumers. For this cases we had to go back and patch the original library, or revert and start from scratch. But even in the easy changes, just the "bureaucracy" of opening tens of pull-requests, watching a few CI pipelines and getting them approved by different code owners was also large.
Now, whenever we have changes in one of the core libraries, we also run full tests in the library consumers. With tests running in parallel, sometimes it takes 20 minutes (instead of 4, 5 hours) to get a patch affecting all frontends tested, approved and merged into the main branch.
Also, everyone agreed that having multiple PRs open is quite stressful.
- nitrogen 5y agoNow, whenever we have changes in one of the core libraries, we also run full tests in the library consumers. This can also be done with CI triggers across repos.
- ratww 5y agoFor most CI/host combinations this requires an ad-hoc solution involving calling APIs that's hardly trivial, both for triggering the CI and blocking the PR. We didn't want to change our perfectly fine solution. Thus, the monorepo killed a handful of birds with one stone.