Adopting Monorepos |
We hear about it all the time: teams have built their applications as mono repositories and have had killer success across the board. Businesses benefit, technology benefits, performance improves—you name it and we've seen it! However, you may think monorepos won't work for you. You already have your infrastructure set up, and it would be way too much effort for your product team to migrate over, right? Wrong.
If you are a software lead with an existing product looking to learn how to transform your product and your team to a monorepo, then this presentation is for you. OpenForge will present to you real strategies and exact implementations for converting your current team into a monorepo team.
💡 Powered by:
Jedidiah Weller CEO & software guru at OpenForge
Fernando Del Olmo Software Engineer at OpenForge
Maria Jose Mendez Software Engineer & Architect at OpenForge
First of all, we are going to describe what is a Mono Repository:
A monorepo (mono repository) is a single repository that stores all of your code and assets for every project.
Here you can find some benefits of mono-repos:
Productivity & Time Savings
Improved code sharing
Enhanced cross-team collaboration
Ability to easily assign ownership
Decreased overhead costs (and headaches)
Enforce code ownership.
And as you can start thinking, there is not information about HOW you are gonna be able to migrate your team to a monorepo architecture, thankfully we did it, and we had some lessons learned along the way that want to share with you.
First we detected our first symptoms:
We were having more than 1 repo to a single product, we used to have a frontend, a backend and a API repositories.
Of course, since we were building software towards a single product, we noticed we use the same services, data models and functionality in all the 3 repositories.
When having to maintain 3 different repositories, change a single data model could be a nightmare if you are not used to share code between your applications
Having 3 different repositories with almost the same modules and packages were not the best way to reuse and save time when building and deploying.
Here is how our old folder structure looked when we first attempted to create a mono repo:
And here, you can see our new folder structure, and its right away benefits:
After we learned how to do it, we discovered a few things you will take into consideration when migrating a team.
Step #1 - Resource Allocation
Work the with team to identify Libraries
Applications, Features, UI, Util, Data-Access, etc.
Assign Code Ownership
Schedule Cross-Team collaborations
Step #2 - Creating the Repo
Initialize repo using Nrwl’s NX Guidelines
Create skeleton of the
Re-review your initial architecture!
Step #3 - Setup Enforcements
This is our basic recommendation to enforce quality code:
Step #4 - Naming Conventions
THIS... this is a very important step, you really need to sit down and discuss the best naming convention that works for your company and team.
Create initial libraries with NX Generate
Create initial components with NX Generate
Create all initial blank UI Components
Re-review naming conventions BEFORE adding any logic
Review as a whole, per library / application.
Step #5 - Migration!
Feature Owners start migrating components first
Start with Libraries
Then Applications (front-facing)
Then Server Apps
We hope you enjoy this small guide about monorepos, If you want to know more, please see our recorded talk here:
And, don't forget to follow us