2 hours agoCreated a post • 15 points @askl
Mostly agree with the article. To me the problem is about dependency management. I see all the time codebases hugely fragmented at the level of git which is totally ad-hoc. After a while, teams face a lot of issues the most annoying being one change in the product involving N PRs with N code reviews and N CIs. This fragmentation of knowledge also pop-ups in weird integration bugs that could be solved with better tool enforcing clearer processes.
The ultimate goal of Reviewpad (https://reviewpad.com) is to allow the benefits of the monorepo approach independently of how the codebase is fragmented at the git level. We are starting from the perspective of code review and debugging (e.g. code reviews with multiple PRs, or code reviews across multiple projects). For people doing microservices like us, the ability to have a single code review for both library and clients has been quite positive so far.Reply
This seems exactly wrong to me. Getting rid of complicated deployment lifecycles is exactly the job that people use monorepos to solve. Wasn't that one of the reasons they are used at Google, Facebook, etc? As well as being able to do large-scale refactors in one place, of course.
> It's particularly easy to see that the "atomic changes > across the whole repo" story is rubbish when you move > away from libraries, and also consider code that has > any kind of more complicated deployment lifecycle, > for example the interactions between services and > client binaries that communicate over an RPC interface.
You should be able to merge a PR to cause a whole system to deploy: clients, backend services, database schemas, libraries, etc. This doesn't preclude wanting to break up commits into separate chunks or to add non breaking change migration patterns into libraries.
What you want to avoid is needing to do separate PRs into 10+ backend services and clients, since: (1) when the review is split into 10+ places it's easier for reviewers to miss problems arising due to integration, (2) needing to avoid breaking changes can sometimes be impossible or so difficult that people will make mistakes doing it, and (3) when there are 10+ separate PRs into different repositories these tend to start independent CI processes that will not test the system as-it-will-be (unless you test in production or have a very good E2E suite -- which would be a good idea in this situation).Reply
Interesting idea and it certainly makes sense to ensure working software at all times.
However it doesn’t have to be one or the other.
Sometimes a single commit (or PR if you prefer multiple commits) can update the api and all clients at the same time.
Sometimes client callers are external to the repo/company. In which case backward compatibility strategy is needed.
There is no need to abandon a concept of a single repo just because you might not use one of the main benefits all the time.Reply
Either way, you've got to do the tooling work to make your chosen approach work. There's no free lunch here.Reply