5 ms·

Hmm, if you're working on a single product (like the author is), then of course it makes sense to stick them in the same repository. But isn't this just common

Hmm, if you're working on a single product (like the author is), then of course it makes sense to stick them in the same repository. But isn't this just common sense? I mean, if you have a single product split over many repositories then you will run into the issues mentioned by the author: A change will invariably involve multiple repositories. Again, to me this seems to be just an indication that you are, in fact, working on a single product.

TickleSteve 7y ago
This is obvious to me (a monorepo advocate) but most people these days tend to organise their repos based on module/implementation lines rather than on product boundaries. My motto is: "What you release together, you should version-control together".
- Conan_Kudo 7y ago
  I'm a multirepo advocate, but I suggest splits similarly. Maybe it's my old-timey way of releasing software, but because I do releases as RPMs, it bothers me less if you do things like have your base library, your backend services, and your frontend in the same repo. If they need to be able to be deployed independently, I just split them up as subpackages. I guess most language package managers don't really have such a concept, so people are optimizing for that...
- ctroein89 7y ago
  I've learnt that for "What you release together, you should version-control together", the phrase "released together" needs to be defined as "what gets globally updated at once". If you provide anything for customers to implement, you cannot update those globally at once (because you need the customer to update), and should think about using a multi-repo set-up. My experience is that testing the interactions of historic versions of different components in a mono-repo against each other is difficult. With a multi-repo set-up, one can checkout to whatever historic version one needs to test. That makes it trivially easy to set-up testing that allows one to test historic versions of components against each.
- adrianN 7y ago
  I like having one repo for the project ("What you release together") that tracks subprojects as submodules.
lukasLansky 7y ago
It's a common sense, but it's really hard to argue against super-fine splitting. Having repo per module seems like stronger separations of concerns from a distance. Of course, what in the end really decides about the strength of your concern separation is the shape of your CI, but alas, repository granuality is just much more visible then CI checks.
- royjacobs 7y ago
  I would argue that if you have clear separation of concerns you wouldn't need to make changes in multiple repositories all the time.
  - lukasLansky 7y ago
    Well let's take frontend/backend separation in a classic webapp -- let's not think about React for now. This makes good concern separation as rendering HTML is something else than computing prices. If you put frontend and backend into different repositories, you need to make two PRs for every new feature and -- for much worse -- you make integration testing much harder as you don't have atomic product merges to run automation against. Don't laugh about this example, my corporation is doing stuff like this (backend only repo tightly coupled to frontend repo) all the time. So maybe we can steelman the argument into "good vertical concern separation doesn't force you into doing multiple PR for single feature, as opposed to horizontal frontend/backend/repository splits."? But I'm still not sure. Wide integration testing is necesity for reliable microservices. It's difficult to do that with dependencies being out of the scope of the change.
    - royjacobs 7y ago
      Integrating with other products is something that goes beyond the scope of SCM repository layout, though. If you change your API then clearly someone on the other side also needs to adjust, but that's not simply sending a pull request. That's also making sure you deploy your products in the right order, ensure backwards compatibility and so on. Re integration testing: That's why things like contract testing are becoming more popular. You make sure that you do as much testing as you can without relying on an entire ecosystem of depdendencies being available, so once you DO release something you can be fairly confident that it's already working as expected.
dalore 7y ago
Sounds like you need/could split it up into core/engine functionality, and then implementation of that core in different environments (i.e. a ios and android one). That makes sense to me, to have 3 repositories. Common code, perhaps even in your own dsl. And then implementations done in the various platforms.
enraged_camel 7y ago
What about a single product with multiple components though? Let's say you have an API and a browser client (SPA). Should you keep them in the same repo, or separate them? So far the only good reason I've had for separating them has been related to deployment concerns (e.g. your API is deployed to AWS and your browser client is on Cloudflare).
- royjacobs 7y ago
  If you have an API and a SPA that's tightly coupled then, yes, same repo. If your API is a separate product with a separate release cycle, proper testing and backwards compatibility checks, then different repo.
viraptor 7y ago
> then of course it makes sense to stick them in the same repository. But isn't this just common sense? It depends. Are you planning more projects which may share functionality? Are you going to release within a company with other teams that may want to integrate? Are some components managed by dedicated teams who may have their own cycles of work? Are you planning to split off a specific service soon? Or to quote risky business: what is the problem we're trying to solve?
- dkersten 7y ago
  > ... may ... If something only may be the case, then I'd say its premature effort to plan for something that may or may not happen. Better to do the simplest thing now and then refactor when the need arises.

TickleSteve 7y ago

This is obvious to me (a monorepo advocate) but most people these days tend to organise their repos based on module/implementation lines rather than on product boundaries. My motto is: "What you release together, you should version-control together".

Conan_Kudo 7y ago
I'm a multirepo advocate, but I suggest splits similarly. Maybe it's my old-timey way of releasing software, but because I do releases as RPMs, it bothers me less if you do things like have your base library, your backend services, and your frontend in the same repo. If they need to be able to be deployed independently, I just split them up as subpackages. I guess most language package managers don't really have such a concept, so people are optimizing for that...
ctroein89 7y ago
I've learnt that for "What you release together, you should version-control together", the phrase "released together" needs to be defined as "what gets globally updated at once". If you provide anything for customers to implement, you cannot update those globally at once (because you need the customer to update), and should think about using a multi-repo set-up. My experience is that testing the interactions of historic versions of different components in a mono-repo against each other is difficult. With a multi-repo set-up, one can checkout to whatever historic version one needs to test. That makes it trivially easy to set-up testing that allows one to test historic versions of components against each.
adrianN 7y ago
I like having one repo for the project ("What you release together") that tracks subprojects as submodules.

lukasLansky 7y ago

It's a common sense, but it's really hard to argue against super-fine splitting. Having repo per module seems like stronger separations of concerns from a distance. Of course, what in the end really decides about the strength of your concern separation is the shape of your CI, but alas, repository granuality is just much more visible then CI checks.

royjacobs 7y ago
I would argue that if you have clear separation of concerns you wouldn't need to make changes in multiple repositories all the time.
- lukasLansky 7y ago
  Well let's take frontend/backend separation in a classic webapp -- let's not think about React for now. This makes good concern separation as rendering HTML is something else than computing prices. If you put frontend and backend into different repositories, you need to make two PRs for every new feature and -- for much worse -- you make integration testing much harder as you don't have atomic product merges to run automation against. Don't laugh about this example, my corporation is doing stuff like this (backend only repo tightly coupled to frontend repo) all the time. So maybe we can steelman the argument into "good vertical concern separation doesn't force you into doing multiple PR for single feature, as opposed to horizontal frontend/backend/repository splits."? But I'm still not sure. Wide integration testing is necesity for reliable microservices. It's difficult to do that with dependencies being out of the scope of the change.
  - royjacobs 7y ago
    Integrating with other products is something that goes beyond the scope of SCM repository layout, though. If you change your API then clearly someone on the other side also needs to adjust, but that's not simply sending a pull request. That's also making sure you deploy your products in the right order, ensure backwards compatibility and so on. Re integration testing: That's why things like contract testing are becoming more popular. You make sure that you do as much testing as you can without relying on an entire ecosystem of depdendencies being available, so once you DO release something you can be fairly confident that it's already working as expected.

dalore 7y ago

Sounds like you need/could split it up into core/engine functionality, and then implementation of that core in different environments (i.e. a ios and android one). That makes sense to me, to have 3 repositories. Common code, perhaps even in your own dsl. And then implementations done in the various platforms.

enraged_camel 7y ago

What about a single product with multiple components though? Let's say you have an API and a browser client (SPA). Should you keep them in the same repo, or separate them? So far the only good reason I've had for separating them has been related to deployment concerns (e.g. your API is deployed to AWS and your browser client is on Cloudflare).

royjacobs 7y ago
If you have an API and a SPA that's tightly coupled then, yes, same repo. If your API is a separate product with a separate release cycle, proper testing and backwards compatibility checks, then different repo.

viraptor 7y ago

> then of course it makes sense to stick them in the same repository. But isn't this just common sense? It depends. Are you planning more projects which may share functionality? Are you going to release within a company with other teams that may want to integrate? Are some components managed by dedicated teams who may have their own cycles of work? Are you planning to split off a specific service soon? Or to quote risky business: what is the problem we're trying to solve?

dkersten 7y ago
> ... may ... If something only may be the case, then I'd say its premature effort to plan for something that may or may not happen. Better to do the simplest thing now and then refactor when the need arises.