What exactly is mono-repo?
A mono-repository is a version-controlled repository that contains many related but independent projects. These can be managed by the same team or multiple teams.
Mono-repos are sometimes called “monolithic repositories” but let’s not get confused with monolithic software architecture.
What exactly is multi-repo?
When a project receives its own version-controlled repository, it is called multi-repo structure, which is the exact opposite of mono-repo. Currently, the majority of developers uses multi-repo structure to maintain their projects.
What are the advantages of mono-repo?
Monorepo has many advantages, but I’ll just mention a few here:
- Consistency: Because all of the projects are stored in the same repository, we can easily enforce the same coding style across all of them.
- Simpler dependency management: Using a modern dependency management tool makes it incredibly easy and simple to distribute dependencies among all the projects. Additionally, the package download for each project will be optimised depending on the package manager. Indirectly, the dependency tree will be simpler and cleaner.
- Easy patch management: Since all of the shared dependencies are in one place, we can quickly upgrade all of the projects’ versions of them. This saves us a lot of time, which allows us to perform more exciting work.
- Easy onboarding process: When a new member joins the team, it becomes simpler for them to understand the code and business flow as all the code is in the same repository.
- Unified build process: We can easily reuse the build process across projects.
- Easy global refactoring: We can easily refactor connected business flow across projects with the help of IDE.
What are the drawbacks of mono-repo?
With lots of benefits, monorepo has a couple of drawbacks. Those are as follows:
- Large codebase: The codebase eventually grows very huge because all the projects are kept in the same repository.
- Lengthy CI/CD process: (Can be managed by advanced build tools.) As all the projects are in the same repository, sometimes we need to unnecessarily build and test projects that do not have any code changes. It increases the code-to-production time.
- Heavy version control history: With a large codebase, version control history also becomes very heavy. It takes a long time to initially clone the repository on the local development system. It also creates issues when we are trying to find a bad commit.
- Learning curve: Once the codebase becomes large, it might impact the learning curve of a new team member.
How can you move from multi-repo to mono-repo?
After knowing both the side of mono-repo structure, if you want to switch from multi-repo to mono-repo; all you have to do is move the relevant projects to the new repository. In this new repository, each project can have its own folder. Once every project has been migrated to a single repository, attempt to move shared dependencies, configurations, and CI/CD workflows to the root level. Test your application once it is complete to ensure that every feature works as expected.. If everything works fine, then voila! You have successfully created a mono-repo project structure 🎊👏.
Best practices for mono-repo project structure
Mono-repo makes a couple of things a little more complex than usual multi-repo projects, but if we keep the following points in mind, life can be a little simpler:
- Invest in tools: you need to find and use suitable tools to manage monorepo. For example, Lerna makes it very easy to manage Node.js mono-repo projects. There are other tools like Bazel, Buck, etc. that support multiple languages.
- Add proper tests: Add multiple levels of automated tests (unit tests, integration tests, architecture fitness tests, etc.) to keep the main branch clean.
- Better CI/CD process: With better and faster CI/CD, the code-to-production time issue can also be minimised. Therefore, we have to use suitable and modern CI/CD.
Conclusion
As you can see, monorepo has lots of benefits and drawbacks. Now, if your question is, “Should I use Monorepo for real-life projects?” Then the simple answer is, “It depends.” 😅. There is no straight answer for this question. For some teams, it might be better to start with mono-repo over multi-repo or vice versa. It doesn’t matter what we choose; it can be changed in the future. We have to keep in mind that it’s not about the technology; it’s about communication and collaboration among team members.
PS: I hope you’ve enjoyed it, and if you’ve found it useful, please feel free to share it with others or leave a comment.
Originally posted on medium.com.