Should we use a monorepo?

Question

My team is planning a migration from subversion to git. We support 3 applications... 1 is primarily for internal users, 1 is for corporate "partners" and 1 is for end users. These applications share some code and also communicate with each other using web services and message queuing. They have different release schedules.

Currently they each have separate subversion repos (so 3 repos). We use the subversion "externals" feature to share the code, including the "contracts" for message queuing.

How should we go about deciding whether to keep the 3 repos when we move to git, using submodules or some other repo sharing technique, or whether we should adopt a monorepo?

Answer 1

My 2 cents: I'd put them in different repos.

• it's easier to track changes (history, blame...)
• it's easier to deal with different release cycles (tagging, version branching...)
• it's easier to deal with (less merges, less branches, no files/dependencies from other projects...)

...as for your "shared code", I'd place it in a lib of its own, in a repo of its own. Or, if it's just about interfacing, declare one project as a dependency of another.

Answer 2

They have different release schedules.

This indicate that you should not have them in the same git repository.

These applications share some code

Move that into a shared library used by your three products, using the appropriate dependency management system for your platform. Put that in a separate git repository too.

So, four git repositories.

Answer 3

TL;DR: I am a consultant working for a government client. We are using submodules for some of our packages. It's quickly becoming frustrating. If you're used to thinking of your packages as being the thing you branch and commit, it's probably not that big of a deal to stick with three repos + submodules.

With that said, if things start to grow and evolve...

This seems a more personal preference question. I think it comes down to two primary things (as I am currently investigating doing this myself).

1. Information architecture.
2. Code promotion strategy.
3. Private versus public modules.

The project I am putting under consideration started as a monolithic application (I really dislike this term) using Laravel. As it grew, I broke into down into services, which I then put into a folder within the overarching application:

- /app
- /app-internal-packages

Then the project reached a point where the Laravel application didn't really contain any custom code; so, I pulled all the services out into separate modules. Some public and some private.

This worked pretty well, except now I needed a way to quickly mimic packagist (or do something else interesting) when developing locally. Further, there's not a lot of sane documentation around using Composer (the package manager for PHP) with public and private repos...at least not sane in my mind. Ticket tracking terrors - each repo has its own set of tickets and my users aren't going to know which service to put the tickets in on GitHub...hopefully you get the idea. Separate repositories can and do work under certain circumstances. Here's what we have now - the notation is [PrR] = Private Repo and [PuR] = Public Repo (change "site" to "application" for your case):

Private repos:

• site one
• site two
• site three
• site four
• internal point system
• newsletter system
• trainer system
• conference system

Public repos:

• authentication package
• policy display system
• ui styles and interactions package
• payment system
• profile system
• super universal code
• ui package
• markup builder
• policy docs
• event registration

Regarding some of the public repos, they are only public because it was so annoying (or costly) to keep them private, that we decided to re-engineer them in such a way as to make them public.

The benefit, of course, is that now all four sites can share that code. But I'm starting to question the reality of that situation, because of our code promotion strategy. Essentially, if it gets used twice in the same scope, promote it to the highest level of that scope (if that makes sense). So, for example, the super universal code started inside one of the sites. it got promoted to the highest level of that site (global, for lack of a better term), then someone wanted it in another site; so, we chucked it in there.

What we're considering moving to:

Private repo:

• sites
  • site one
  • site two
  • site three
  • site four
• internal point system
• newsletter system
• trainer system
• conference system

And possibly pulling some of the public repos back into being private. No need to worry about submodules or package management. Code promotion doesn't result in going to a different repo entirely. No build step necessary when doing local development. Launching the latest version of all the apps is a git pull and possible public package update for all the sites. And, each domain name can just point to a sub-folder inside of one of the site directories.

In other words, there's a lot of benefit to going the monorepo route. There's alos a lot of benefit to going the route you are considering. And, even though there is a little more detail in the question, as a coach and a consultant, I don't think there's enough to give a canonical answer or advice.

Answer 4

The answer can be very nuanced depending on a wide variety of factors (long answer in this article on monorepo vs polyrepo that I wrote). Regardless of whether you use a monorepo or a polyrepo, I would consider splitting the code into separate modules, where the shared code is part of one or more such modules. Then each of these modules could have their own release schedule.

So even if they coexist in a single repository, these modules could be released asynchronously. Tangent: A common mistake with monorepos is to think that if your changes are atomic across multiple projects, then the release is atomic too. That is unrealistic at scale and it creates the habit of monolithic releases, which slow down your agility.

There are many other aspects to consider when deciding monorepo vs polyrepo, however one of the most important considerations to make is whether the tooling available out there (open-source or commercial-off-the-shelf) is prepared for monorepo. For example, most CIs don't handle monorepos well and the build systems that do (eg Bazel) are very difficult to migrate to and embrace as a team.

Answer 5

You can read this article where you can get a short compariosn between the monolithic architecture, Micro frontend architecture and Monorepo architecture. SO that we will help to give the clear picture of pros and cons w.r.t. the application and its scenarios. and How monorepo architecture can be scale up to build enterprise level application with greater scalability. https://pushkarkinikar.wordpress.com/2022/09/12/why-monorepo-need-of-large-scale-application/