3 ms·
We tried at Spotify the multi-repo thing and it was a total nightmare. Once you have lots of people working on a product, it becomes very hard to do changes on
by ardit33 6y ago
We tried at Spotify the multi-repo thing and it was a total nightmare. Once you have lots of people working on a product, it becomes very hard to do changes on a multi repo setup.
The alternatives:
1. Completely de-coupled code. I.e. teams ship libraries, like a 3rd part api. This slows down development considerably, and makes re-use of code harder.
2. Keep everyone on one repo, and allow to changes stream in.
1. Slows down dev. (it suddenly becomes more beourocratic), 2. requires scaling your code versioning tool (gir/mercurial, etc) and processes associated with it.
Also, single repos, make sense in one domain (e.g. server side, ios, android, etc...). You can have different repos for different 'domains' where code doesn't intersect with each other that much.
- dehrmann 6y ago> makes re-use of code harder I've found this to be a feature of polyrepos because monorepos can easily become a rat's nest of dependencies. Polyrepos make you think harder about what should really be exposed and shared.
- jonhohle 6y agoA phrase I like to use sums this up: “dependencies are easy to add, but hard to remove.”
- joshuamorton 6y agoBuild systems can enforce visibility, which solves this. Allowing fine grained visibility at the level of a file, package, or artifact is better than at the granularity of a repo.
- dehrmann 6y agoDepends how easy it is to change visibility. My point is polyrepos make things you need to be careful about like adding internal dependencies and API changes hard. Monorepos make those deceptively easy.
- joshuamorton 6y agoIt's not clear how a monorepo makes you changes hard (not why they should be). They're really easy when you can do them atomically, and even the hard cases are easier in a monorepo than multi. (And at least at Google visibility changes required the approval of the team who you want to depend on)