Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Titel: Monorepos bei Uber: 👍 oder 👎?
Wichtige Keytakeaways
- Monorepos sind große Repositories, die den Code mehrerer Projekte oder Services enthalten.
- Bei Uber gibt es mehrere Monorepos, aufgeteilt nach Programmiersprachen.
- Das Go-Repository enthält ca. 3000 Microservices.
- 50% der Änderungen betreffen nur einen Service, aber 0,1% der Änderungen betreffen über 2000 Services.
- Uber nutzt ein Kohorten-basiertes Deployment-System für große Änderungen, um die Risiken solcher Deployments in den Griff zu bekommen.
- Die Kohorten werden nach Kritikalität (Tiers) unterschieden, zunächst werden weniger kritische Services deployt.
- Weitere Deployments der betroffenen Services werden gesperrt, bis das Kohorten-basierte Deployment durchgelaufen sind
Behandelte Kernfragen
- Wann sind Monorepos sinnvoll bzw. nicht sinnvoll?
- Wie geht man mit übergreifenden Änderungen in Microservice-Architekturen um?
- Wie lassen sich Deployments bei tausenden Services koordinieren?
- Wie kann man Risiken bei systemweiten Änderungen minimieren?
- Steht das Konzept im Widerspruch zur Microservice-Philosophie der Unabhängigkeit?
Glossar wichtiger Begriffe
- Monorepo: Ein Repository, das mehrere Projekte oder Services enthält
- Trunk-Based Development: Entwicklung auf einem Hauptzweig ohne langlebige Feature-Branches
- Kohorte: Gruppe von Services, die gemeinsam deployed werden
- RPC Library: (Remote Procedure Call) Library für Netzwerkkommunikation
- Feature Toggle: Mechanismus zum Ein-/Ausschalten von Features in Produktion
- Cherry-Picking: Selektives Auswählen bestimmter Commits für ein Release