CI / CD for Monorepos

Introduction to Monorepos 

Monorepos can be a great force for fostering rapid development workflows. But, are they the right fit for you, your team, and your company?

1.1 What Is a Monorepo? 

Not everyone agrees on a single definition for monorepo. Some may only accept the term when it applies to companies hosting all their code in a single repository. Google is the most famous example of this; their monorepo is theorized to be the largest code repository in the world, which has thousands of commits per day and exceeds 80 TBs in size.

More relaxed definitions will say that a monorepo is a version-controlled code repository holding a number of independently-deployable projects. While these projects may be related, they are often separate, logically-independent, and run by different teams. For instance, Airbnb has two monorepos: one for the frontend code and one for the backend code. In this way, a company or organization can utilize multiple monorepos.

Monorepos are sometimes also called monolithic repositories, but they should not be confused with monolithic architecture, a software development practice for writing centralized applications using a single codebase. To give one example to these kinds of architectures, think of a Ruby on Rails application handling websites, API endpoints, and background jobs all at once.

1.2 Monorepos vs. Multirepos 

The opposite of the monorepo is a multirepo, or simply repos, where each project is held on a completely separate, version-controlled software repository. Multirepos come naturally — it’s what we do when starting a new project. After all, who doesn’t like starting fresh?

Moving from multi to monorepo is merely a matter of moving all your projects into a single repository.

$ mkdir monorepo
$ git init
$ mv ~/src/app-android10 ~/src/app-android11 ~/src/app-ios .
$ git add -A
$ git commit -m “My first monorepo”

Of course, this is just to get started. The hard work comes later, when we get into refactoring and consolidation. To enjoy the full benefits of a monorepo, all shareable code should be moved outside of each project folder and into a common location.

Multirepos are not a synonym for microservices. In fact, having one does not require using the other. Later, we’ll discuss companies using monorepos with microservices. A monorepo can host any number of microservices as long as you carefully set up your Continuous Integration and Delivery (CI/CD) pipeline1 for deployment.

1.3 What Monorepos Bring to the Table 

At first glance, the choice between monorepos and multirepos might not seem like a big deal. On closer inspection, however, it’s a decision that deeply influences how you and your team interact.

Monorepos have the following benefits:

• Visibility: everyone can see everyone else’s code, leading to better collaboration and cross-team contributions. Any developer can fix a bug in your code before you even notice it.
• Simpler dependency management: sharing dependencies is trivial. There’s little need for a complex package manager setups as all modules are hosted in the same repository.
• Single source of truth: one version of every dependency means there are no versioning conflicts and no dependency hell.
• Consistency: enforcing code quality standards and a unified style is straightforward when you have your entire codebase in one place.
• Shared timeline: breaking changes in APIs or shared libraries are immediately exposed, forcing different teams to communicate and join forces. Monorepos keep everyone invested in keeping up with changes.
• Atomic commits: atomic commits make large-scale refactoring possible. In theory, a developer can update several packages or projects at once in a single commit. In practice, these types of changes are usually rolled out in stages, not all at once.
• Implicit CI: continuous integration is guaranteed as all the code is already integrated into one place.
• Unified CI/CD process: you can use the same CI/CD deployment process for every project in the repo.