Mono Repository oder Multi Repository

Vergleich

Im Folgenden sind die Notizen aufgeführt, die im Vorfeld für die Gruppendiskussion über Mono- vs Multi-Repository gemacht wurden.

Multi Repository

Vorteile

• Clear Ownership: Jedes Team hat seinen eigenen Verantwortungsbereich
• Smaller Code Base: Jedes Repo hat seine eigene Codebasis
• Narrow clones - Continious Deployment: Da die Codebasis relativ klein ist, ist auch die download/clone Zeit geringer, was dazu führt, dass auch die Zeit für das builden und deployen schnell geht.

Nachteile

• Bei steigender Menge an Microservices/Repositories unübersichtlich
• Viele pulls über verschiedenste Repos (Lösungsansatz: Ein sogenanntes Metarepo, welches ein Einheitliches Repo für verschiedene Operationen simulert: Tool für ein "Metarepo")

• Abstracts the knowledge of the platform: Da jedes Team nur für einen Service verantworlich ist, kann die Integration zum Problem werden und die Kenntnisse der Plattform insgesamt abnehmen.
• Sharing of common Codes: Es ist über verschiedene Repos schwerer gemeinsamen Code zu Teilen. (Es erfordert gewissen Aufwand dies möglich zu machen)

Mono Repository

Vorteile

• Easy Sharing of common Codes
• Better developer testing
• Better overall understanding
• Standardization - Reduced code complexity
• Easy Refactoring and reviews: Da sich der Code am selben Ort befindet, ist es einfacher diesen zu Refactorn und zu reviewen.

Nachteile

• Larger Code Base
• Greater Clone Time - Continious Deployment: Aufgrund der größeren Code Basis wird auch die download/clone Zeit erhöht. Dies resultiert wiederum in einer höheren Build- bzw. Deployment-Zeit.

Empfehlungen

• Multiple Repos verwenden und zur Organisation, gerade, wenn die Anzahl der Repos steigt, ein Metarepository verwenden (Quelle: medium.com/@patrickleet)

• "We believe mono repos are the right choice for teams that want to ship code faster"(Quelle: shippable.com)

• Der schwerwiegendste "Schwachpunkt" von Mono Repositories, der auch die meisten Entwickler dazu bringt mehrere Repos anzulegen, ist die Frage, wie das CI/CD mit einem großen Repo funktionieren soll. (Hier wird erklärt, wie eine CI/CD Pipeline für ein solches Repo angelegt werden kann: http://blog.shippable.com/ci/cd-of-microservices-using-mono-repos)

Wie machen's die "Großen"?

Monorepos

• Google
• Facebook
• Twitter

(Companies like Twitter, Google, Facebook run massive monolithic repos with 1000s of developers Quelle: shippable.com https://github.com/twitter https://medium.com/@maoberlehner/monorepos-in-the-wild-33c6eb246cb9

Auf Github

• GoogleCloudPlatform Demo für die Implementierung von Microservices - link
• Babel benutzt Monorepos sehr erfolgreich - link

Multirepos

• Netflix https://www.slideshare.net/reed2001/culture-1798664/11-11CommunicationYou_listen_well_instead_ofreacting

Was bedeutet das für uns?

Für ein relativ kleines Entwicklerteam und wenig Repositories muss nicht unbedingt eine Entscheidung getroffen werden, wie die Repositorys angelegt werden. Hier kommt es dann darauf an welche Vorteile man jeweils nutzen möchte. Momentan sind unsere Repositories nach Domänen strukturiert. Würde man einen Mono- bzw. Multirepository Ansatz umsetzen wollen, müssten entweder alle bisherigen Repositories zusammengefasst werden, oder eine Trennung der Domänenspezifischen Repositories stattfinden. Aufgrund der Unabhängigkeit der Teams, die auch im Sinne des DDD ist, würde es mehr Sinn machen für jeden Microservice ein Repository zu erzeugen, also den Multirepository Ansatz zu verfolgen.

Quellen

• https://medium.com/@somakdas/code-repository-for-micro-services-mono-repository-or-multiple-repositories-d9ad6a8f6e0e
• https://medium.com/@patrickleet/mono-repo-or-multi-repo-why-choose-one-when-you-can-have-both-e9c77bd0c668
• http://blog.shippable.com/our-journey-to-microservices-and-a-mono-repository