Ledger Live Monorepo-Projekt: Teil 1 – Problematik (Make it Pain) | Hauptbuch

In dieser Blog-Beitragsreihe spricht Valentin De Almeida, ein Ledger Live-Entwickler, über die Entwicklung der Ledger Live-Codebasis im Laufe der Jahre. In diesem Blogbeitrag erfahren Sie, dass es zunächst auf mehreren Repositorys basierte, auf welche Probleme wir dabei gestoßen sind und warum es zu einer Mono-Repository-Architektur weiterentwickelt werden musste. In den nächsten Blogbeiträgen erklären wir, wie dieses große Migrationsprojekt durchgeführt wurde. 

Ein bisschen Geschichte 

Das Wachstum von Ledger in den Jahren 2020 und 2021 war erheblich. Wir haben energisch neue Talente rekrutiert und unser Team von nur einer Handvoll auf über 20 Entwickler erweitert. Das bedeutet, dass viele neue Ingenieure in bestehende Projekte eingebunden wurden. Da unser Team schnell wuchs, standen wir vor neuen Herausforderungen, die wir schnell bewältigen mussten. Trotz dieser neuen Schwierigkeiten blieben wir auf unser Ziel konzentriert und leisteten weiterhin außergewöhnliche Arbeit.

Wir traten einen Schritt zurück und untersuchten die neuen Probleme, die entstehen, wenn immer mehr Menschen in das Projekt eingebunden werden. Unter diesen neuen Herausforderungen können wir die folgenden Bedürfnisse aufzählen:

• Einfachere Abläufe.
• Bessere Richtlinien für eingehende und externe Mitwirkende.
• Ein einheitlicher Satz an Werkzeugen.
• Besseres Abhängigkeitsmanagement.
• Zentralisierte Open-Source-Beiträge.

Stand der Technik: vor der Migration

Ursprünglich und bis zum letzten Jahr basierte Ledger Live auf einer Poly-Repository-Architektur, sowohl für mobile als auch Desktop-Frontends, sowie auf der gesamten Logik dahinter. Es war keine bewusste Entscheidung, auf diese Weise zu arbeiten, sondern es war lediglich das Ergebnis eines expandierenden Projekts ohne wirkliche architektonische Führung. Ledger Live ist ein Projekt, das verschiedene Komponenten in einem vereint, um unseren Nano-Benutzern die beste und sicherste App bereitzustellen, und dies spiegelt sich in der Codebasis wider.

Die Abläufe, die wir hatten, waren bestenfalls unregelmäßig, was vor allem daran lag, dass wir vor ein paar Jahren noch sechs oder sieben Entwickler waren. Da weniger Parteien beteiligt waren, war die Kommunikation viel einfacher und wir kamen damit durch. Dennoch gab es einige Schwachstellen in unserer Arbeitsweise, insbesondere im Hinblick auf die Entwicklererfahrung und den Veröffentlichungsprozess.

Engpässe bei der Entwicklungserfahrung

Abhängigkeiten

Aufgrund der Art unserer Projekte arbeiten wir gleichzeitig an mehreren Repositories mit Abhängigkeiten zwischen ihnen. Hier ein kurzer Überblick:

Die Open-Source-Bibliotheken von Ledger werden von der Geschäftslogik verwendet, die dann sowohl von den Desktop- als auch von den mobilen Apps verwendet wird. Aber diese Apps nutzen auch die Open-Source-Bibliotheken und verwenden zwei verschiedene Versionen derselben Bibliothek (wie @ledgerhq/errors zum Beispiel) würde die App kaputt machen.

Wir mussten die Version auf einer Seite aktualisieren, dann die Bibliotheken veröffentlichen (ja, in npm!!!) und es dann erneut versuchen, wenn es nicht funktionierte. Wir begannen, uns darauf zu verlassen yalc um Projekte mit Symlinks zu verknüpfen, was größtenteils in Ordnung war, solange wir nicht mehrere Ebenen von Abhängigkeiten hatten (z. B. von den Open-Source-Bibliotheken zur Geschäftslogik und dann von der Geschäftslogik zu den Apps). Wir haben versuchsweise versucht, mit zu arbeiten yarn link auch, aber es scheint, dass es mit React Native zum Scheitern verurteilt war.

Testen

Es war nahezu unmöglich, Integrationstests mit dem neuesten Code aus den verschiedenen Projekten durchzuführen. Da wir die Bibliotheken in der Registry veröffentlichen mussten, war das Testen aller Komponenten mit dem aktuellsten Code ein Albtraum

Wir mussten auch mehrere CIs mit duplizierter Logik pflegen.

Kontextwechsel

Das ständige Wechseln zwischen mehreren Code-Editoren/Projekten/Verzeichnissen ließ die Entwicklungserfahrung wirklich schwach erscheinen.

Engpässe im Release-Prozess

Versionierung

Der Umgang mit der Versionierung verschiedener Projekte ist schwierig, insbesondere wenn es mehrere Ebenen von Abhängigkeiten gibt.

Releasing

Die Release-Nachverfolgung war kompliziert, da die Projekte aufgeteilt waren und wir die Releases der verschiedenen Projekte verwalten mussten

Es war nicht möglich, den Veröffentlichungsprozess zu automatisieren, da die Projekte in verschiedene Repositories aufgeteilt waren.

Und natürlich war Continuous Delivery zu diesem Zeitpunkt undenkbar.

Mögliche Lösung ?

Wenn wir uns nach Inspiration umsehen, scheint es, dass eine Mono-Repository-Architektur das zentrale Element ist, das uns gefehlt hat. Dies würde einen viel besseren Entwicklungsprozess ermöglichen. Um diese Architektur herum gibt es Tools, die uns helfen würden, die fehlenden Teile (Release, Automatisierung, Versionierung …) zu erreichen.

Aber was ist ein Mono-Repository?

Im Kern ist ein Mono-Repository ein Projekt, das alle anderen zugehörigen Projekte (Anwendungen, Bibliotheken, Tools) in einem Ordner/Git-Projekt kapselt. Es ermöglicht ein besseres Abhängigkeitsmanagement, eine Vereinheitlichung von Tools (wie Codestile und Typoskript-Konfigurationen), eine zentralisierte kontinuierliche Integration, Integrationstests, eine einheitliche Version der verwendeten Pakete (z. B. Reagieren) …

Da es sich um ein ziemlich agnostisches System handelt, mussten wir einige Funktionen noch entdecken und implementieren. Hoffentlich gibt es einige großartige Community-Tools, die uns dabei helfen könnten, Orchestrierung zu den Builds (sequentielle Builds, hilfreich für CI), Versionierung, Änderungsprotokollgenerierung usw. hinzuzufügen, die das vervollständigen würden, was uns in unserem Veröffentlichungsprozess gefehlt hat.

Nachteile

Mono-Repositories sind in einem Kontext sinnvoll, in dem mehrere Entwickler oder ein Entwicklerteam gleichzeitig an mehreren Projekten arbeiten und zwischen ihnen Abhängigkeiten bestehen. Es erhöht jedoch die Komplexität während der Einrichtungsphase (insbesondere bei bereits laufenden Projekten mit einer vierjährigen Geschichte und aktiver Entwicklung). Erwähnenswert ist, dass das Projekt in Bezug auf den Speicherplatz viel größer (viel größer) wird. Alle Projekte befinden sich jetzt im selben Ordner und in allen Abhängigkeiten. Welche Tests sind obligatorisch? Wann sollen sie ausgelöst werden?

Vorteile

Nach Abwägung des Zeitaufwands, der Kosten und der Machbarkeit unserer Ambitionen sind hier einige der erwarteten Vorteile dieses Übergangs aufgeführt:

• Verbessertes Abhängigkeitsmanagement: Mit einem Monorepo ist es einfacher, Abhängigkeiten zwischen verschiedenen Projekten zu verwalten, da sie alle im selben Repository gespeichert sind. Dies kann den Bedarf an Problemumgehungen wie Garnverknüpfung oder reduzieren yalcund erleichtern die Sicherstellung, dass alle Projekte die richtigen Versionen der Abhängigkeiten verwenden.
• Bessere Code-Organisation: Ein Monorepo kann die Organisation von Code erleichtern, da alle Projekte und ihre Abhängigkeiten in einem einzigen Repository gespeichert werden. Es ist einfacher zu verstehen, wie verschiedene Projekte zusammenpassen und wie sie voneinander abhängen.
• Verbesserte Entwicklererfahrung: Ein Monorepo kann Entwicklern die Arbeit an mehreren Projekten erleichtern, da sie nicht zwischen verschiedenen Codebasen oder Repositorys wechseln müssen. Es kann auch die Durchführung von Integrationstests erleichtern, da der gesamte Code im selben Repository gespeichert ist.
• Verbesserte Automatisierung und kontinuierliche Bereitstellung: Mit einem Monorepo ist es einfacher, Aufgaben wie das Erstellen, Testen und Freigeben von Code zu automatisieren. Dies kann dazu beitragen, den Release-Prozess zu rationalisieren und die Implementierung von Continuous Delivery zu erleichtern.
• Erhöhte Entwicklungsgeschwindigkeit. Da verschiedene Teams im selben Repository arbeiten, müssen sie nicht bis zur Veröffentlichung warten, um das Ergebnis zu überprüfen, was die Integration beschleunigt.

Zusammenfassung

Insgesamt kann die Implementierung einer Monorepo-Struktur dazu beitragen, den Entwicklungsprozess zu verbessern, den Release-Prozess zu rationalisieren und die Entwicklererfahrung zu verbessern.

In den nächsten Blogbeiträgen dieser Reihe werden wir Sie durch die Durchführung dieses großen Migrationsprojekts, die von uns verwendeten Tools, die von uns getroffenen Entscheidungen, das Ergebnis und mehr führen. Seien Sie gespannt auf Teil 2: Die Werkzeuge!

---

Valentin DE ALMEIDA
Entwicklererfahrung und Kerntechnologie – Ledger Live

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain