It would seems a new fashion has come to the world of software engineering, which anyone is expected to have an oppion about. The so called mono-repo talk.

As with so many other cases there seems to be multiple definitions flying around and not asserted definition of when you have a mono-repo, but let me try to share some thoughts.

• A repository is a place, where sourcecode (and potentially other stuff) is associated with software development is stored.
• A mono-repository is when all the sourcecode produced in a company is manged in a single repository.
• A Single-server respository (strategy) os whenn all sourcecode is manged in a single (git) server, but every project has its own repository.

On the multi (git)server, multi repository setup…

I don’t like it.

While companies and organizations may have allowed for different source code repository software (CVS, SubVersion, GIT, Mercurial and so on), it should be feasible to choose one and mandate we are all using this in our software toolchain. Most modern software repository have all features needed by anyone and the differences should for almost anyone be insignificant. Pick one and stick to it.

Setting up a source code repository should be a commodity and it should be delivered as part of your software factory. I have seen many cases, where source code was lost simply because a unicorn team insisted on have a “protected server” (and maybe a different tool the rest), but didn’t case enough about it to keep it update, keep it backed up and monitor the operations.

If you don’t have an internal team who provide a software factory - a managed solution from Gitlab, Github or any other modern sourcecode management system, will habe better resilience than something pulled of the shelf.

If you need to install a source code repository softeware, you should absolutely have very strong arguments for why it neeeded and valuable - and you should have dedicated resourced set a side of operations (including updates, backups, integrations to toolchains, monitoring and everything else needed).

Mono-repos - One server, one checkout.

The idea is that all sourcecode is a shared asset for all developers and when you do a checkout, you “get all of it”.

It does provide a single authoritative source of “what source code exist” in the comapny. It makes it easier to onboard people to any project - as they already have access and know where to finde “the source”. I’m not sure I really understand the big gain suggested by this approach. Often sourcecode is written in multiple programming langugages and people mostly work in teams for long periods of time - rarely jumping from project to project. Managing a potentially much larger codebase may have much larger resource requirements (disk space, network bandwidth, time when interacting it the repo).

I suppose such an approach may have advangtages if the company has enforced standardization on the tools used in the software factory

• the build pipelines, how to write and run tests, how deploy builds and how to create shared libries for others to use.

If you’re in such a company - you would know it and may already have considered the mono-repo approach.

Single repo server, multiple repositories…

I do very much belive, that a source code repository server, should be created as a commodity service offered by a single authoritative team which handles updates, monitoring, scaling and any other service needed, to provide it to the rest of the development teams in the organization.

Having a central trusted commodity service allows the comany to harvest most of the benefits of a source code management system, and by consolidating the needs in a single team, they can probably accumulate higher expertice and a higher service level than any distributed approach should be able to provide.

---

#The Danish draft… Om man så skal gå skridtet videre og lave et decideret monorepo, hvor alt koden ligger i samme “checkot”, er så mere kompliceret.

Der er fordele ved det…

• Hvis det er sandsynligt, at udviklere flytter rundt mellem projekter, kan det være en fordel. (så når man først har adgang til repo’et, så har man adgang til alle projekter).
• Hvis man genbruger komponenter/librries på tværs af sine software produkter.
• Hvis man bruger nogle open source frameworks og kun skal opdatere dem engang for at propagere ud til alle projekter, der bruger dem.
• Man kan nemmere få opsat og kørt sikkerheds tools såsom DAST og SATS.

Ulemper tæller blandt andet:

• Når man har store kodebaser, så bliver ens repo interaktioner ofte langsommere.
• Hvorfor blande ting sammen, der ikke har noget med hinanden at gøre?
• Man vælger ofte en “best of breed” i sin tooling omkring et monorepo fremfor at vælge det meste til den specfikke løsning. (build tools, test frameworks, etc)

Jeg tror nok, at jeg er mest til mono-repo server, for at få de fleste fordele, som et monorepo lokker med, men reelt ikke til Monorepos med mindre:

• Man bruger få teknologier (kodesprog, frameworks og anden tooling) på tværs af projekterne.
• Man er villig til at lave et “repo-team”, som driver ens monorepo som en service (opdateringer, performance, backup, support til teams)