3 ms·

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 te

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 will fully cede questionable ROI on this whole exercise. But, I will argue that cuts both directions. That is, I would not push to move from one form to the other. I do like multiple projects being as independent as I can make them, though.

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 will fully cede questionable ROI on this whole exercise. But, I will argue that cuts both directions. That is, I would not push to move from one form to the other. I do like multiple projects being as independent as I can make them, though.