6

We currently have a "front-end" git repository that is all of our JavaScript client apps, and a "back-end" git repository containing all back end APIs written in .NET Core. There is also a few other random repositories built on differing technologies. This is all managed via Azure DevOps, which I believe will let us trigger builds on particular paths.

front-end repo
-- applications
----app1
----app2
-- common-library

back-end repo
-- apis
----api1
----api2
--common-library

some .net-core-product repo

We were considering putting everything in a single mono-repo because it is easier for the developers to manage with git clients such as Visual Studio. I cannot find an example of a multi-language monorepo - is there an example on github? What are the pros/cons?

4

Monorepos have been getting a lot of attention in recent years since google popularized them. If you aren't on a similar scale as google it might not work out as well for you. I've been in a startup that moved to monorepos and we quickly found that:

  • most tools are built with one repo leading to one artifact that gets deployed. You will have to rework all of those tools to handle the monorepo. There are tools that are designed for monorepos.
  • a monorepo puts all of your eggs in one basket. If somebody steals a laptop would you rather them get half of your code or all of it? Keeping things in their own repos reduces exposure.
  • your CI for code validation is now much more complicated. You need to support multiple languages in your code conformance tests. Developers will get upset when you check backend stuff and they've only made frontend changes. Now you're stuck trying to figure out how to disable some CI checks, but make sure they're enabled when needed.

All of this adds up to a load of work for release engineers. Do you have people focused on release engineering with free time to tackle multiple complicated projects? Google can make this work because they have hordes of engineers and they can dedicate ten folks to this sort of thing for months until it is smooth enough to develop on top of. If you are not at the same scale as google you might not be able to follow their example. The folks that have succeeded with this tend to be big organizations. You may not have found an open source example because none exists.

These points are also noted in this article:

The frank reality is that, at scale, how well an organization does with code sharing, collaboration, tight coupling, etc. is a direct result of engineering culture and leadership, and has nothing to do with whether a monorepo or a polyrepo is used. The two solutions end up looking identical to the developer. In the face of this, why use a monorepo in the first place? Please don’t!

So focus on improving your engineering culture and don't get worried about not following the latest tech trends.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.