Search:

Why you should avoid from Monorepo?

Beyond Microservices & Trunk-Based-Development, Fundamental factor for your efficiency in development

Category: Git
Category: Git

Why you should avoid from Monorepo?

 

Development practices have been changing a lot in the last two decades. The ultimate goal of all those efforts is to increase the delivery efficiency and improve time-to-market.


There are several methodologies and frameworks used to increase the overall efficiency. In this article I may refer some of those but will not go deeper as I want to focus on the main topic. Those may include

- Agile Methodologies

- The Twelve-factor App

- Microservices

- Trunk-based Development

...

Waiting is one of the eight lean wastes. This also includes the  waiting time of developers. Every time you add a new functionality or change a functionality, the most popular approach in the market is to have a Monorepo, which does not comply with "Single-Responsibility Principle" .

Monorepo can be defined as a single repository which contains more than one application or infrastructure-related code.

Humans are the determining factor for the efficiency in development pipeline. If you are waiting for your code to be built and run for more than 10 minutes, you will definitely switch your context or give a break. This is a major efficiency problem and it actually happens widely.

Initial repository cloning takes a lot of time. Having a Monorepo just increases your wait times, nothing else! It makes it hard to adopt Trunk-Based Development, even most of the time makes it very hard! Even the changes is the repository are not related with your task or application, you still have to deal with those changes. Your best friends are “git rebase” and “git reset”

The other challenge with Monorepos is keeping the git history clean and lean. Each pull from the origin may bring additional changes to your short-living  branch and making it difficult to shrink the history as it contains other unrelated changes!

If you have a Monorepo, benefiting from webhooks for triggering an automated build after each commit becomes very complex and usually not preferred practically, which means you have to press the "Build" button in your CI tool! This challenges  Continuous Delivery practices.

If you are a Platform Developer, like me, The effects are same like having all the Terraform modules and infrastructure-related code, all in one repository. Recall a fundamental  software development principle: Common/repetitive code which is consumed by more than one consumer should be positioned as a dependency! You can apply this by positioning your Terraform modules to separate repositories and referring them in your code using the git tag versions.

Untitled drawing (2)

Or if you are an application developer, you may see a core repository which has multiple applications in it and when you ask the reason, you may get an answer "They depend on each other or a common code in that repository" . The alternative approach can be to position the common code that your applications depend on, as a separate repository with its own deployment pipeline, because it should be a library!

Software Development projects are still the #1 failed projects as the success is highly dependent on the software development practices being used. And it is obvious that, if you go with an approach which  creates wait times, like using Monorepos, then you are boosting the failure possibility!

 

Derya (Dorian) Sezen

Derya, a.k.a. Dorian, ex-CTO of an amazon.com subsidiary, is currently working as Cloud and DevOps Consultant at kloia. He has migrated 10+ companies to AWS and has been involved in Containerisation and DevOps Automation projects in a range of industries. As a AWS DevOps Professional Certified expert, Derya is mentoring the hands-on trainings.

Want to work with us?

A wonderful serenity has taken possession of my entire soul, like these sweet mornings of spring which I enjoy with my whole heart. I am alone, and feel the charm of existence in this spot.

Contact us