Monorepos have gained popularity in large organizations such as Google and Facebook as of late. The concept at first seems to go against the computer science ethos of breaking things into small modular pieces.
Large centralized organizations often have dozens, maybe hundreds, of microservices and components that talk to each other. Many of these share dependencies, test infastructure, and are often written in the same programming language. The same engineers may even work across these microservices. In this case, version controlling all these services in a monorepo is a good idea and can often simply things like testing and CI. All the parts can be tested together, so it’s easier to make sure the contracts between them don’t break. Furthermore, all developers are kept in the loop when updating and merging code. The advantages here outweigh the drawbacks of having a large sized repo that’s constantly changing.
Monorepos make less sense in smaller organizations that may have an architecture based on a few components, especially if these are composed of different languages and frameworks, and don’t share too many dependencies. Each repo can be tested and developed in isolation, without being unecessarily polluted with code and checkins from repos that don’t share much in common. Monorepos also don’t make sense in organizations that open source a lot of code. It’s easier for the consumer of a service to only pull in the necessary library or framework, without anything extraneous.
A good hybrid approach that provides advantages of both is to manage issues for all repos in a central organizationl-level project management tool, like Github Projects. This way, all developres are kept informed of changes to all repos. Pull requests can reference issues across all repos and notify all developers.
Ultimately, deciding between multiple repos and monorepos is, like all things in a technology, is a matter of tradeoffs depending on the needs of your organization. Moving to a monorepo architecture is easier than breaking up a monorepo into individual ones, so I would always start with individual repos and migrate to a monorepo if the need occurs. Facebook and Google didn’t start with them afterall.
TruStory decided to use multiple repos for now, since we plan on open sourcing parts of our codebase in the future.