München Open Source

Deutsch

English

Deutsch

English

Darstellung

Repositories ​

Public Code definiert sich durch freie Lizenzen, aber auch durch öffentlich zugänglichen Quellcode und Artefakte.

Code ​

Wir wollen Bürger*innen, Entwickler*innen anderer Behörden, Citizen Developer, grundsätzlich allen interessierten Menschen, die Möglichkeit geben unseren Code zu verwenden, verstehen, verbreiten und auch zu verbessern.

GitHub ist das bekannteste öffentliche Code-Repository für freie Software. Nutzer*innen aus der FOSS-Community suchen, teilen und diskutieren freien Code hauptsächlich auf GitHub. Wir richten uns nach der Community und nutzen ebenso GitHub für Public Code der Landeshauptstadt München. Durch die Codeverwaltung und CICD auf GitHub bieten wir eine niederschwellige Teilhabe für alle an.
GitHub hält keinerlei beschränkende Rechte an dem dort verwalteten Code, jedes Projekt kann seine Lizenz selbst bestimmen. Dies führt zu einer geringen Herstellerabhängigkeit, der außerdem leicht zu entkommen ist: Wir sind nur an Git als freie Software zur verteilten Codeverwaltung gebunden. Diese wird auch von allen anderen relevanten Plattformen genutzt. Wie andere freie Projekte, z.B. curl, halten wir uns offen, andere auf Git basierende Plattformen zusätzlich oder auch alternativ zu nutzen.

Wenn wir uns an anderen Softwareprojekten beteiligen, tun wir dies auf der existierenden Plattform des Softwareprojekts.

Eine für die Öffentlichen Verwaltungen in Deutschland wichtige relevante Alternative ist gitlab.opencode.de. Dazu betreiben wir dort die Gruppe landeshauptstadt-muenchen. Auch wenn wir auf gitlab.opencode.de nicht primär veröffentlichen, sind wir auf Anfrage bereit, Repositories dorthin zu spiegeln. Wenn wir uns an freien Softwareprojekten anderer Communities aus der öffentlichen Verwaltungen beteiligen wollen, werden wir das ausschließlich dort machen, sofern die Projekte MergeRequests erlauben.

Um Mitarbeitende nicht zu zwingen, mit Klarnamen im Internet zu agieren, dürfen Mitarbeiter*innen Pseudonyme nutzen. Um aber nachvollziehen zu können, welche Mitarbeitenden hier öffentlich agieren, sind alle genutzten Pseudonyme intern dokumentiert.

Artefakte ​

Das Konzept Public Money Public Code verpflichtet nur, den Quellcode zu veröffentlichen. Um eine einfache Nutzung unserer Software zu ermöglichen, wollen wir möglichst viele auf dem Quellcode basierende Artefakte wie gebaute Pakete, Container-Images oder Helm Charts veröffentlichen.

Repository-Struktur ​

Software-Repositories können unterschiedlich strukturiert sein. Ob ein Projekt-Repository oder ein Multi-Repository-Ansatz gewählt wird, sollte stets eine gut begründete, projektspezifische Entscheidung sein.

Beide Varianten haben ihre eigenen Stärken und Schwächen. In vielen Fällen empfiehlt sich ein Projekt-Repository, es gibt jedoch auch nachvollziehbare Gründe, die für ein Multirepo sprechen. Wir nutzen beide Ansätze: Als Beispiel für ein Projekt-Repository das Wahllokalsystem und für Multirepo die dave- Projekte.

Im Zweifelsfall sollte ein Projekt-Repository bevorzugt werden.

Diese Empfehlung gilt insbesondere für Projekte auf GitHub, ist aber grundsätzlich auf jedes Git-Repository (z.B. git.muenchen.de) anwendbar.

Projektrepo ​

Ein Projektrepo ist eine Softwareentwicklungsstrategie, bei der der Code für mehrere zusammengehörige Services innerhalb eines Projekts in einem gemeinsamen Repository verwaltet wird. Im Gegensatz dazu stehen Multirepos, bei denen jeder Microservice in einem eigenen Repository gepflegt wird.

Vorteile eines Projektrepos:

  • Abhängigkeiten zwischen Services innerhalb eines Projekts (z. B. ein neues Feature, das Änderungen im Frontend und Backend erfordert) können gemeinsam entwickelt, getestet und released werden – inklusive Pull Requests, Tests und Deployments.
  • Ein Projektrepo erleichtert es Außenstehenden, schnell zu erkennen, welche Komponenten zusammengehören.
  • Entwicklerinnen und Entwickler können eine vollständige Entwicklungsumgebung mit allen benötigten Diensten einfacher aufsetzen.
  • Es gibt eine zentrale README.md, die eine übersichtliche Dokumentation des Gesamtprojekts bieten kann. Ergänzend empfiehlt sich eine Doku-Website in einem /docs-Verzeichnis oder als eigenständige Doku-Website.
  • Die Gesamtübersicht auf GitHub (z. B. github.com/orgs/it-at-m/repositories) bleibt übersichtlich, da weniger Einzel-Repositories entstehen.

Ein Projektrepo eignet sich besonders für Projekte, in denen viele Services eng miteinander verzahnt und voneinander abhängig sind.

Multirepo ​

Für Multirepos spricht:

  • Jedem Microservice ist genau ein Repository und eine Pipeline zugeordnet. Dies macht die Entwicklung übersichtlicher.
  • Ein Projekt, das aus verschiedenen Services mit unterschiedlichen Technologien besteht, kann in einem Monorepo zu Vermischungen und ggf. zu Merge-Konflikten führen, die für Personen ohne Kenntnisse in Technologie A oder B schwer zu lösen sind.
  • Pipelines sind in der Regel weniger kompliziert als in einem Projektrepo.
  • Weniger Daten als bei einem Projektrepo: Das Klonen eines einzelnen Repositories und das Nachvollziehen von Änderungen (z. B. mit git blame) gehen schneller.
  • Fehler im main branch betreffen in der Regel nur einen Microservice, können sich aber auch auf abhängige Services oder das gesamte Produkt auswirken.

Multirepos eignen sich vor allem für eigenständige Services und insbesondere für Libraries, die in anderen Projekten genutzt werden sollen.

Monorepo ​

Spricht man von einem Monorepo-Ansatz, bedeutet dies im Prinzip, dass es nur ein einziges Repository im gesamten Unternehmen gibt. In diesem Repository sind alle Projekte des Unternehmens enthalten. Dazu gehören sowohl aktive als auch inaktive Projekte. Der bekannteste Fall eines Monorepos im produktiven Einsatz ist Google, das ein eigenentwickeltes Sourcecode-Management-Tool gebaut hat, um damit genau ein einziges Repository zu verwalten. Auch Meta Platforms, das Unternehmen hinter Facebook und Instagram, setzt im Wesentlichen auf ein Monorepo, bei dem die Git-kompatible Eigenentwicklung Sapling zum Einsatz kommt, die Ende 2022 als Open Source veröffentlicht wurde.
So ein Monorepo ist verdammt riesig und enthält die Historie von (fast) allen Projekten der Firma.

aus Sujeevan Vijayakumaran: DevOps Wie IT-Projekte mit einem modernen Toolset und der richtigen Kultur gelingen ISBN 978-3-8362-9099-9 5.5.4 Was ist eigentlich mit Monorepos?

A monorepo is a single repository containing multiple distinct projects, with well-defined relationships.

aus monorepo.tools

Der Größe eines Monorepos sind praktisch keine Grenzen gesetzt:

Google, for example, is theorized to have the largest code repository ever, which has thousands of commits per day and is over 80 TBs large.

aus semaphoreci.com - What is a monorepo?

Ein Monorepo bei der LHM wäre beispielsweise dann gegeben, wenn Refarch, alle Refarch-Projekte, das BayernID-Plugin als unabhängiger, aber genutzter SSO-Dienst und weitere Projekte gemeinsam in einem einzigen Repository verwaltet würden.

Regeln ​

  • Dokumentation: Die zahlreichen Services in einem Monorepo sollten in der README.md dokumentiert und mit Links auf die jeweiligen Dateien oder Verzeichnisse versehen werden.
  • Namenskonvention: Jedes Repository, das zum Multirepo eines Projekts oder Produkts gehört, ist mit einem einheitlichen Prefix und einem - zu benennen (z. B. dave-).