The traditional way of managing your organisation or department’s codebase – the sum of all the different kinds of code that contribute to your product – is to store each component, service, tool, infrastructure or testing automation separately, each in their own repository. This is clearly inspired by the way open source software development is done, where every small tool or library is built by a different person or team.

In many organisations, this is often not the case. Frequently, the same group of people work on all of these things together, which allows for a much more light-weight management of the various components and their mutual dependencies, enabling the removal of strict repository boundaries and instead of storing all of your codebase in a single repository – a so-called ‘monorepo’.

Monorepos have several benefits compared with the traditional strategy, recently dubbed ‘poly-repo’. To start with, everyone has visibility of the entire codebase and can contribute (with review) to every part of it, helping to foster a culture of collaboration. Continuous integration and delivery systems can be set up once for everyone. And having a single timeline of changes allows for changes to be made to several components of your overall system, in sync.

Knowing the dependencies between the components, these can be automatically tested, even against all of their known consumers, drastically reducing the feedback time on changes made, when compared to the traditional, semi-manual versioned release workflow. As long as your automated testing is thorough, broken changes don’t even make it into the master branch, let alone in front of customers.

With tools like Kubernetes, Istio, and Terraform all the code contributing to your product can be stored together and changed together, allowing you to treat a distributed application like a monolith. The boundaries of various applications and systems are also more flexible this way, enabling easy changes in ownership and helping you avoid the pitfalls of the infamous Conway’s Law.

Tooling for monorepos is still not as well developed as we’d like, but there’s a clear trend towards teams joining their poly-repos together and the tooling (e.g. GitHub) improves to follow. The only remaining issue to solve if your organisation grows to a large scale (we’re talking hundreds of engineers over several years) is scaling the repository management service to match. But fortunately, the industry giants have blazed that trail for us and can offer some solutions.

Our take on monorepos? They make the development of moderately complex systems faster. They make thorough continuous integration and automated testing easier. And they lower the barriers to safely sharing code across projects. Plus, they’re a good strategic choice for a flexible source code management strategy – one that’ll set you up for the future.