Multi Vs Mono Repo
Finding the Right Balance ⚖️
Hello everyone! This is my first Medium post, I hope I can make an interesting contribution to our beautiful community. 😊
We will examine the benefits and drawbacks of the multi-vs.-mono repo strategies on Git.
This could be a useful document to compare which solution will work best for your project, including overall pain points from the team, optimizing the build time, etc., We will talk about the pros and cons of both strategies.
Multi Repo Strategy
Every feature is being developed as a cocoapod or module, and each will have its own git repository. Team members that are working on modules will only push their code to module repositories, and the main app will add them to the project through cocoapods/devpods as a framework dependency. Let’s see its benefits
Pros:
i) Less code conflict, Since each module will have its own repositories, code conflicts will be very minimal and will not take subsequent time for developers to resolve, if any.
ii) Each module/feature will be developed and tested independently on its unique repository
iii) Shorter CD build time
iv) Less load on the Jenkin node agent means more performance
v) Smaller test reports are easier to review per module, if any
vi) Since all modules are being fetched as cocoapods, this reduces the amount of time the app needs to compile and build.
Cons:
i) Versions must be resynchronized across dependencies and other libraries, as well as in the primary workspace.
ii) When a team just concentrates on their modules or features, they run the risk of losing their sense of teamwork, being unable to investigate the tech backlogs in other sections of the application, and maybe even failing to keep up with any new knowledge regarding other components or features of the whole application.
iii) Have to maintain lots of repositories
iv) It can lead to code redundancy if teams are not syncing up on a regular basis for overall code health.
Mono Repo Strategy
The majority of apps adhere to this pattern. All teams are required to commit their code to a single repository in order to have their work merged into the master/release branch of the project’s single git repository, which contains the project’s features, backlog, and future development-related subbranches. Check out its advantages.
Pros:
i) One source of truth, containing all branches, offspring branches, and other project-related repositories in one location.
ii) increase cooperation and team spirit while working together
iii) Any tech backlog in another section of the main app may easily be reviewed or reported.
iv) It’s advantageous for new members since they just need to clone one repo and any associated branches.
Cons:
i) Code conflicts (rebasing or merging for developers) may be quite serious issues if the app’s code is fairly large and numerous people are merging or providing PRs on a regular basis. It may take a long time for those who are in charge of handling master or release repositories for releasing versions, cutting tags for release, or helping teams merge their code into the master or release branch.
ii) By putting the build in the queue for numerous events for the main repositories, it can overburden the entire CD process.
iii) The length of the app building will increase with the project size. Some enterprise apps are so big that the initial indexing and building process takes 5 or 6 minutes on average; sometimes it's longer too. That kills developers' time.
If you choose to use a multi-repo or mono-repo strategy for your projects, it all depends on how your project is structured and what your pain points are.
There are a few additional issues to take care of if you want to move forward with multi-repositories.
i) How to handle dependencies
ii) Common components i.e. extensions, localization, accessibility, etc,
iii) Asset Centralization
iv) Network calls
Conclusion
In the end, a variety of factors will determine whether you decide to switch or not. Because it can take a long time to make changes, tech companies occasionally decide to continue with the current code and structure. Other crucial factors include deciding how many developers to engage separately for this task and how to support both current and upcoming releases. If your team regularly participates in code health check-ups, that is a fantastic approach to discussing such topics and determining whether they can alleviate your pain points. You can then decide after hearing what your teammates and product owners have to say.
Please express your opinions. I welcome any feedback.
Thank you!
