5 ms·

> 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"

> 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.
- klodolph 5y ago
  Ok, that's a good example. I've just never seen that stuff make it past code review. Teams I've been on, development & deployment are either done by the same team, or they're done by two teams who sit next to each other. Reviewers are also very skeptical of larger changes. I still don't see advantages to multi-repo here. Even within a single project, or single service, deployment is often not atomic. If you make a change to service X and deploy it, you end up with minimum two versions of service X in deployment until the deployment finishes rolling out. So we have automated tests that cover that case... each service has to work correctly when combined with not only the repo HEAD, but also with the currently deployed versions (perhaps more than one! in the case I'm thinking of, it was only ever the two previous versions, but other teams had longer horizons) Testing against multiple versions is a bit more expensive, so it's only done as a pre-deployment check, rather than a pre-commit check. You cut a branch for deployment, and when one commit doesn't play nicely with previous versions of the service, you cherry-pick a commit to revert the faulty commit, and run the tests again.
  - taeric 5y ago
    Same situation here. And we have always had tests, too. Hard to force mixed fleet behavior in most tooling, though. And teams grow, such that relying on code review to catch things is really a best intentions. Putting it in your face that you are changing two projects is about the best I can offer here. I would cede that this, too, is mainly a best intentions. But having as close to 1:1 between code changes, deployment changes, and code reviews at least puts things on mainly equal footing. That is, when the explanation of why some code can't deploy together is that they are in two projects, and you can see that by them being separate repositories, that feels easier than knowing that two parts of a single repository have to deploy separately.
    - klodolph 5y ago
      It just seems like such a miniscule benefit, and you have to deal with the massive headache of a multi-repo setup. If you don't want people making changes to multiple projects at the same time, it would be trivial to add a pre-submit check to enforce that anyway. There's no need to switch your entire repository layout just to remind people that the code in different folders belongs to different projects.

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.

klodolph 5y ago
Ok, that's a good example. I've just never seen that stuff make it past code review. Teams I've been on, development & deployment are either done by the same team, or they're done by two teams who sit next to each other. Reviewers are also very skeptical of larger changes. I still don't see advantages to multi-repo here. Even within a single project, or single service, deployment is often not atomic. If you make a change to service X and deploy it, you end up with minimum two versions of service X in deployment until the deployment finishes rolling out. So we have automated tests that cover that case... each service has to work correctly when combined with not only the repo HEAD, but also with the currently deployed versions (perhaps more than one! in the case I'm thinking of, it was only ever the two previous versions, but other teams had longer horizons) Testing against multiple versions is a bit more expensive, so it's only done as a pre-deployment check, rather than a pre-commit check. You cut a branch for deployment, and when one commit doesn't play nicely with previous versions of the service, you cherry-pick a commit to revert the faulty commit, and run the tests again.
- taeric 5y ago
  Same situation here. And we have always had tests, too. Hard to force mixed fleet behavior in most tooling, though. And teams grow, such that relying on code review to catch things is really a best intentions. Putting it in your face that you are changing two projects is about the best I can offer here. I would cede that this, too, is mainly a best intentions. But having as close to 1:1 between code changes, deployment changes, and code reviews at least puts things on mainly equal footing. That is, when the explanation of why some code can't deploy together is that they are in two projects, and you can see that by them being separate repositories, that feels easier than knowing that two parts of a single repository have to deploy separately.
  - klodolph 5y ago
    It just seems like such a miniscule benefit, and you have to deal with the massive headache of a multi-repo setup. If you don't want people making changes to multiple projects at the same time, it would be trivial to add a pre-submit check to enforce that anyway. There's no need to switch your entire repository layout just to remind people that the code in different folders belongs to different projects.