4 ms·
We're pretty small scale (< 20 services, < 10 devs), and happily use a monorepo (recently moved from multiple repos when that became unwieldy as services grew).
by grey-area 8y ago
We're pretty small scale (< 20 services, < 10 devs), and happily use a monorepo (recently moved from multiple repos when that became unwieldy as services grew). If you have a lot of services/projects with some shared dependencies they can make tracking that easier. I agree with the article that in general they make life easier.
It depends on what tooling you're using, and whether it is tied to the version control system. Clearly if the tooling makes assumptions about one deployable per repo and works on git hooks that's going to cause pain, but the answer is don't use monorepos if your tooling doesn't support it, or change the tooling so it does.
Most companies won't scale past a few hundred employees, so they're never going to hit any sort of scale issues with monorepos, and if they do, they'll have the resources to deal with it.
Does this have to be a religious war? Does one size fits all really apply here?
- shados 8y ago> We're pretty small scale (< 20 services, < 10 devs) This is really important and the whole point, indeed. Eg: We consider our org to be "many repos" (we have several thousands). However, hundreds of them contain 5, 10, or 20+ packages/projects/services. It's funny because we'll talk about creating "monorepos" (plural) for certain part of our product, and it confuses the hell out of people.
- aidos 8y agoSeveral thousand repos - ye gads! How do you document them? How do they fit together? Do they reference each other?
- shados 8y agoThe answers to all those questions are "it depends". There's a few thousand libraries, those obviously refer to each other.. Some have readme files and that's enough, some have full documentation "books", some have comments in the code and that's enough. We don't mandate a company wide development process, so each team and groups can choose their own process and how they track their stuff. We do have automation and tooling to keep track of things though.
- gowld 8y agoYou are talking about creating "oligorepos".
- robaato 8y agoMaybe an "omnirepo"?! (Though risks connotations with "omnishambles" - https://en.wikipedia.org/wiki/Omnishambles https://en.wikipedia.org/wiki/Omnishambles
- tln 8y agoHow does CI work here? Do you kick off tests and deploys for 20 services when any one changes?
- lkschubert8 8y agoMost CI (and a decent amount of CD) tools I know allow you to specify what to run based on subfolder in a repo.
- grey-area 8y agoNo, only those that are impacted. Most services are pretty standalone, those that share code we try to put tests for that shared code in with the shared code. I don't think CI tooling needs to be tied to a given repo, that's just one way to do it.