The article fails to discuss the ever-popular lots-o-monorepos approach ;) I really liked the idea behind the approach I learned from the linked-in tools team:

The article fails to discuss the ever-popular lots-o-monorepos approach ;) I really liked the idea behind the approach I learned from the linked-in tools team: project-oriented build-test-deploy tooling. In this approach, it doesn't matter how the projects map to repos. instead, the tooling specifies a canonical way to declare projects (including owners) and their dependencies. The build tool takes care of placing the dependencies in the project build environment, and enforces versioning (like if a library author needs to yank a version because of a bug). This approach lets library authors make changes without having to update all use cases. They still get to yank versions and test new versions against all use cases in an infra. The project owners get control of their dependencies -- they get to choose what to use and when to build and deploy updates, but also can't fall hopelessly behind on updates -- the build tool won't let them, and they can see which dependencies need updates. My favorite part is that the build tool can be used for both internal and external dependencies -- who works on them or where they're stored is irrelevant. I haven't had a chance to implement this approach, but it sounds promising. I also like the migration path -- most companies should probably start with multiple repos to take advantage of open-source and hosted tooling, and this approach allows incremental migration to get advantages of mono-repo without a painful all-or-nothing migration.