5 ms·

> To me the whole point of a monorepo is atomic commits for the whole org. The belief that a monorepo makes a change somehow more atomic is one of the traps.

> To me the whole point of a monorepo is atomic commits for the whole org. The belief that a monorepo makes a change somehow more atomic is one of the traps. From the article: > The greatest power and biggest lie of the monorepo is that it is possible to make atomic commits across your entire codebase. [...] > Your monorepo now contains many different deployable artifacts that deploy at different times. It is also technically possible to make, for example, a breaking change to a service’s interface, a service’s implementation, and the service’s clients all in one PR. However, this PR will break when you deploy it because you do not deploy your service and all of its clients atomically. While this is also possible in a world with many repositories, the requirement to do this change in multiple pull requests is often enough to remind engineers that breaking changes to a service contract are not safe to make. > Your users must understand that your deployment system operates asynchronously with respect to what happens in the monorepo. Its primary interaction with the monorepo is to go and pick up the “latest” build artifacts for a particular service; everything else happens on timetables that are potentially not under your control and can happen arbitrarily far in the future. > A common CI job in a monorepo is to validate service contracts and make sure that they are not broken unless the author deliberately intended to do so, and they are required to provide a justification as to why such a change is OK.

crazygringo 1y ago
That's confusing two different things, though. A monorepo does make changes atomic in the code. There's no trap there. You're talking about deployment, and yes when deployment is staggered, then obviously all atomic changes need to be backward-compatible, or else be very carefully orchestrated. But that doesn't have anything to do with monorepo vs polyrepo. That's just staggered deployment. You have to deal with backwards compatibility in both cases. But at least with the monorepo you can see and track and merge all the changes related to a feature in one place, and be able to roll them back in one place.
- yencabulator 1y ago
  There's no such thing as when deployment is staggered. It's a distributed problem, so by definition it is not synchronous. (Or you turn services off for the duration of the deploy. Most companies do not want that these days.) Also, you're missing this part of the article: > While this is also possible in a world with many repositories, the requirement to do this change in multiple pull requests is often enough to remind engineers that breaking changes to a service contract are not safe to make.
  - crazygringo 1y ago
    I was talking about the concept of deployment in general. Yes, of course it's usually staggered for monorepos. I don't know why you're arguing about saying there's "no such thing as when" and then immediately point out a case of "when" immediately following. (And turning off services for 15 minutes at 2 am is definitely still a thing.) And I'm not missing any part of the article. I was talking about your comment, and the fact that you are conflating two different things. A monorepo allows you to make atomic commits that a polyrepo does not, full stop. There's no trap there. Deployment is separate. You have to worry about breaking changes regardless of it being a polyrepo or monorepo. But a monorepo can make each atomic change far easier to track and manage and reason about.
- oftenwrong 1y ago
  There is also a question of what developers should be developing against. A typical monorepo approach allows many developers to develop only against trunk, and not have to allow the messy world of releases and deployments into their brain.

crazygringo 1y ago

That's confusing two different things, though. A monorepo does make changes atomic in the code. There's no trap there. You're talking about deployment, and yes when deployment is staggered, then obviously all atomic changes need to be backward-compatible, or else be very carefully orchestrated. But that doesn't have anything to do with monorepo vs polyrepo. That's just staggered deployment. You have to deal with backwards compatibility in both cases. But at least with the monorepo you can see and track and merge all the changes related to a feature in one place, and be able to roll them back in one place.

yencabulator 1y ago
There's no such thing as when deployment is staggered. It's a distributed problem, so by definition it is not synchronous. (Or you turn services off for the duration of the deploy. Most companies do not want that these days.) Also, you're missing this part of the article: > While this is also possible in a world with many repositories, the requirement to do this change in multiple pull requests is often enough to remind engineers that breaking changes to a service contract are not safe to make.
- crazygringo 1y ago
  I was talking about the concept of deployment in general. Yes, of course it's usually staggered for monorepos. I don't know why you're arguing about saying there's "no such thing as when" and then immediately point out a case of "when" immediately following. (And turning off services for 15 minutes at 2 am is definitely still a thing.) And I'm not missing any part of the article. I was talking about your comment, and the fact that you are conflating two different things. A monorepo allows you to make atomic commits that a polyrepo does not, full stop. There's no trap there. Deployment is separate. You have to worry about breaking changes regardless of it being a polyrepo or monorepo. But a monorepo can make each atomic change far easier to track and manage and reason about.
oftenwrong 1y ago
There is also a question of what developers should be developing against. A typical monorepo approach allows many developers to develop only against trunk, and not have to allow the messy world of releases and deployments into their brain.