Monorepo Strategy

What goes into a monorepo depends on the scope that is defined for it. We currently identify five distinct levels of scope for monorepos:

Highest Level: All the software a company produces is held in the repository. This is famously the case at Google, which stores billions of lines of code in a single repository. As a agency working with multiple clients, we don't see this level of monorepo at Factorial.

High Level: All the software components related to a particular client are held in the repository. We see this becoming an option at Factorial when we work with our clients on larger parts of the software ecosystem.

Medium Level: Components related to a project are held in the repository. These components usually share code via libraries. This is a common level of monorepo we see and is what we will use when we adopt a service-oriented architecture.

Low Level: A monorepo groups together components that compose and form, from the viewpoint of a user, a single application.

Lowest Level: Even in apparently monolithic systems, there are at least frontend and backend components, which you may want to develop independently although they are part of the same system. In such cases, stepping into a monorepo can be a good idea as well.

We are now assessing to bring the approach to Circle Dot and thus to all our future Drupal-based projects.

We are trying out using the monorepo approach for Website Standards, as we're having clearer boundaries between workers, supporting services and the main system.