3 ms·

> The problem with trying to force one single history, is that it ignores deployments. I'm not sure what, exactly, the problem is that you're talking about. Wh

> The problem with trying to force one single history, is that it ignores deployments. I'm not sure what, exactly, the problem is that you're talking about. When you deploy something, it's built from a specific commit. Deployment is not atomic, it's a gradual process that takes some amount of time. Between when you (or your automation) chooses to deploy a system and when the deployment finishes is some window of time. The system will often spend much of that time in a partially updated state. You may also choose to canary changes, so you will have a mix of different versions in production at any given time. At companies where I've worked, the time from deployment start to finish for backend systems ranges anywhere from hours to weeks. I don't understand how this relates to multi-repo or mono-repo concerns, however. The repo is a history of the source code (intentional changes by humans), it's not a history of the state of your production systems (which are the results of automation).

taeric 5y ago
Many of the mono repo guides I see are off the "all projects in one repository" kind. If the project doesn't build and deploy as an atomic unit, then having atomic code changes is a foot gun. It is amazing how many times I've seen folks think that just because they can get build time tests happy with changes in two projects, that they can safely send out the two changes. Does a multi repo "solve" this? Of course not. But it is easier to reason that two projects clearly need two deploys. Versus having to remember that one commit could be N project deployments.
- klodolph 5y ago
  > ...then having atomic code changes is a foot gun. Why is it a foot gun? I don't know what the negative consequences are here. Atomic commits are just to make development easier. It means that you can refactor downstream dependencies in the same commit that you make a change to an upstream library. This way, you either build and deploy the new library + the refactored downstream dependency, or you build and deploy the old version, but never some mix. It reduces the number of possible configurations that can be built & deployed, since you can only pick from a point in one repo's history, and you can't mix and match various points in the history of different repos. With multi-repo, it is harder to discover down-stream dependencies. > It is amazing how many times I've seen folks think that just because they can get build time tests happy with changes in two projects, that they can safely send out the two changes. Build-time tests don't catch 100% of errors. Some errors will still make it into production. I don't see how this problem is related to the multi-repo vs mono-repo problem at all. At places where I've worked, if you change project X and project Y, and your commits pass the build test, you still have to submit the commits in some linear order. The pre-commit tests for X will include Y or vice versa. X or Y will be rebased or merged on top of the other one, and the result will have to go through pre-commit tests. I am just trying to understand what problem multi-repo is supposed to be addressing here, and I don't have the slightest clue what you're getting at.
  - taeric 5y ago
    I call it a foot gun because of how many times I've seen people shoot themselves in the foot. My assertion is that the "build and deploy new code with updated downstream users" only works in a minority of cases. Now, I grant that this could be due to the micro service nature of where I'm at. And I also grant that it is nice when this can work. However, the times it goes wrong are usually not at all worth the risk.
    - klodolph 5y ago
      > I call it a foot gun because of how many times I've seen people shoot themselves in the foot. I understand what "foot gun" means. Explaining what "foot gun" means is not helpful. What I don't understand is the problem that "shooting yourself in the foot" is a metaphor for. > My assertion is that the "build and deploy new code with updated downstream users" only works in a minority of cases. There are two main cases here: libraries and services. Libraries can be atomically updated no problem, most of the time. You change a function and fix the call sites. For services, you have to add to the API, deprecate the old thing, refactor the clients, and then remove the old thing after all the clients have been rebuilt and redeployed. At least two steps. What I don't understand is how this would be different for multirepo or monorepo setups. In either case, removing some old piece of functionality requires waiting until the clients have been redeployed. Using new functionality requires waiting until the server has been redeployed. > Now, I grant that this could be due to the micro service nature of where I'm at. The teams where I've used monorepos are also the teams with the most buy-in to microservice architecture. One team I was on ran a service that consisted of something like twenty different microservices. These interacted with services run by other teams. Everything was in the same monorepo. It worked fairly smoothly, as I recall--we spent most of our time solving domain problems and working on our team's core mission, and I don't remember any problems arising from the monorepo setup. It sounds like your experience is different, and I was hoping that you would share some of that experience.
      - taeric 5y ago
        I have seen people review and ship code that was all consistent in a single commit, that had to be deployed in separate deployments. In the mixed fleet scenario that this leads to, I have seen failures that require gymnastics to fix. Yes, you can do similar with reviews that span multiple projects. However, I have seen it happen far more times in single repositories than I have in multiple ones. Again, I am not in any way offering a panacea. I'm just saying that seeing things as atomic at one level leads people to think they are atomic at the next level. And this is a mistake I've seen many many times. Yes, I have seen people manage it somewhat well. But every effort I have been involved with that tried to merge code history between projects has had more faults of this kind than the other projects I have been on.

taeric 5y ago

Many of the mono repo guides I see are off the "all projects in one repository" kind. If the project doesn't build and deploy as an atomic unit, then having atomic code changes is a foot gun. It is amazing how many times I've seen folks think that just because they can get build time tests happy with changes in two projects, that they can safely send out the two changes. Does a multi repo "solve" this? Of course not. But it is easier to reason that two projects clearly need two deploys. Versus having to remember that one commit could be N project deployments.

klodolph 5y ago
> ...then having atomic code changes is a foot gun. Why is it a foot gun? I don't know what the negative consequences are here. Atomic commits are just to make development easier. It means that you can refactor downstream dependencies in the same commit that you make a change to an upstream library. This way, you either build and deploy the new library + the refactored downstream dependency, or you build and deploy the old version, but never some mix. It reduces the number of possible configurations that can be built & deployed, since you can only pick from a point in one repo's history, and you can't mix and match various points in the history of different repos. With multi-repo, it is harder to discover down-stream dependencies. > It is amazing how many times I've seen folks think that just because they can get build time tests happy with changes in two projects, that they can safely send out the two changes. Build-time tests don't catch 100% of errors. Some errors will still make it into production. I don't see how this problem is related to the multi-repo vs mono-repo problem at all. At places where I've worked, if you change project X and project Y, and your commits pass the build test, you still have to submit the commits in some linear order. The pre-commit tests for X will include Y or vice versa. X or Y will be rebased or merged on top of the other one, and the result will have to go through pre-commit tests. I am just trying to understand what problem multi-repo is supposed to be addressing here, and I don't have the slightest clue what you're getting at.
- taeric 5y ago
  I call it a foot gun because of how many times I've seen people shoot themselves in the foot. My assertion is that the "build and deploy new code with updated downstream users" only works in a minority of cases. Now, I grant that this could be due to the micro service nature of where I'm at. And I also grant that it is nice when this can work. However, the times it goes wrong are usually not at all worth the risk.
  - klodolph 5y ago
    > I call it a foot gun because of how many times I've seen people shoot themselves in the foot. I understand what "foot gun" means. Explaining what "foot gun" means is not helpful. What I don't understand is the problem that "shooting yourself in the foot" is a metaphor for. > My assertion is that the "build and deploy new code with updated downstream users" only works in a minority of cases. There are two main cases here: libraries and services. Libraries can be atomically updated no problem, most of the time. You change a function and fix the call sites. For services, you have to add to the API, deprecate the old thing, refactor the clients, and then remove the old thing after all the clients have been rebuilt and redeployed. At least two steps. What I don't understand is how this would be different for multirepo or monorepo setups. In either case, removing some old piece of functionality requires waiting until the clients have been redeployed. Using new functionality requires waiting until the server has been redeployed. > Now, I grant that this could be due to the micro service nature of where I'm at. The teams where I've used monorepos are also the teams with the most buy-in to microservice architecture. One team I was on ran a service that consisted of something like twenty different microservices. These interacted with services run by other teams. Everything was in the same monorepo. It worked fairly smoothly, as I recall--we spent most of our time solving domain problems and working on our team's core mission, and I don't remember any problems arising from the monorepo setup. It sounds like your experience is different, and I was hoping that you would share some of that experience.
    - taeric 5y ago
      I have seen people review and ship code that was all consistent in a single commit, that had to be deployed in separate deployments. In the mixed fleet scenario that this leads to, I have seen failures that require gymnastics to fix. Yes, you can do similar with reviews that span multiple projects. However, I have seen it happen far more times in single repositories than I have in multiple ones. Again, I am not in any way offering a panacea. I'm just saying that seeing things as atomic at one level leads people to think they are atomic at the next level. And this is a mistake I've seen many many times. Yes, I have seen people manage it somewhat well. But every effort I have been involved with that tried to merge code history between projects has had more faults of this kind than the other projects I have been on.