5 ms·
The company I work for has recently transitioned from many small repos to a single monorepo. I can tell you that the development experience is MUCH better. 99%
by Hendrikto 4y ago
The company I work for has recently transitioned from many small repos to a single monorepo. I can tell you that the development experience is MUCH better. 99% of issues required cross-repo coordination, which was a nightmare, and thing could easily get out of sync.
With a monorepo, you don‘t need to think about which commits work with which other commits. One commit ID is a full description of every subcomponent.
- tootie 4y agoI don't really understand how that creates fewer bottlenecks. It may save communication overhead because every dev can spot integration issues on their own, but at the cost of monstrously complex and time-consuming build-and-test pipelines. The microservice approach just requires some kind of service contract and meaningful release versions. That's always been a very manageable cost in my experience.
- yakkityyak 4y agoIn my experience the Uber mono repo was a giant velocity killer. Go tooling just completely choked, and at the time they had tons of terrible hacks around go modules by having this weird system that required your mono repo to be in GOPATH, further breaking even more tooling. No clue if that’s fixed today but it soured the idea of monorepos for me, and that’s not incorporating how often submitqueue would go down.
- ferdowsi 4y agoThe sharing of service contracts and their shared dependencies is a difficult problem to solve by itself. There's companies trying to make money off of the problem (buf). Monorepos solve the problem out of the box.
- sagarm 4y ago> just requires some kind of service contract and meaningful release versions. I've just switched to a company with many tiny repos and IMO it's a huge hassle. There's no automated integration testing, and manual integration testing is a huge pain to set up. I don't even know how I'd create integration tests that run as part of the CI. What version would I use? If you need to change both sides (very common), coordinating the commits and releases is very painful. The "monstrously complex" build-and-test pipelines are a significant cost, but the alternative is higher release failure rate and moving slower overall IMO.
- preseinger 4y agoIf 99% of issues required cross-repo coordination, then those repos by definition should not have been distinct from each other. Splitting code into separate repos only makes sense if changes can be shipped in isolation. 1 repo == 1 bounded context == 1 isolated unit of deployment.
- joshuamorton 4y agoThen any time you have fan-shaped dependencies, you need a monorepo. Which, well, the Uber people clearly have since these big changes exist.
- AlexanderDhoore 4y agoNo true scotsman would split up repos wrong.
- zero_shift 4y ago> 1 repo == 1 bounded context == 1 isolated unit of deployment. The most obvious counterpoint: many systems of record need to scale command operations (writes) and query operations (reads) separately. So you absolutely would have separate programs, ASGs etc for those two roles
- preseinger 4y agoHow is this a counterpoint?
- zero_shift 4y agoThey wouldn’t have a single deployment but exist in one bounded context.
- preseinger 4y agoOh, indeed, my mistake. A team can of course deploy its bounded context at whatever granularity it prefers. The important thing is just that that deployment schedule is unrelated to the deployment schedule of other teams/contexts.