Ledger Live Monorepo Project: Del 1 – Problematik (Make it Pain) | Hovedbog

I denne blogindlægsserie fortæller Valentin De Almeida, en Ledger Live-udvikler, os gennem Ledger Live-kodebasens udvikling gennem årene. I dette blogindlæg vil du lære, at det var multi-depot-baseret i starten, de problemer, vi stødte på undervejs, og hvorfor det var nødvendigt at udvikle sig til en mono-repository-arkitektur. I de næste blogindlæg vil vi forklare, hvordan dette store migrationsprojekt blev gennemført. 

Lidt historie 

Ledgers vækst i 2020 og 2021 var betydelig. Vi rekrutterede aggressivt nyt talent og udvidede vores team fra kun en håndfuld til over 20 udviklere. Det betyder, at en masse nye ingeniører blev involveret i eksisterende projekter. Da vores team voksede hurtigt, stødte vi på nye udfordringer, som vi hurtigt skulle tage fat på. På trods af disse nye vanskeligheder forblev vi fokuserede på vores mål og fortsatte med at levere exceptionelt arbejde.

Vi tog et skridt tilbage og undersøgte de nye problematik, der opstår, når flere og flere mennesker meldte sig ind i projektet. Blandt disse nye udfordringer kan vi nævne følgende behov:

• Enklere flows.
• Bedre retningslinjer for indgående og eksterne bidragydere.
• Et samlet sæt værktøjer.
• Bedre afhængighedsstyring.
• Centraliserede open source-bidrag.

State of the Art: før migrationen

Oprindeligt, og indtil sidste år, var Ledger Live baseret på en poly-repository-arkitektur, til både mobile og desktop front-ends, samt al logikken bag. Det var ikke en bevidst beslutning at arbejde på denne måde, men det var kun resultatet af et ekspanderende projekt uden reel arkitektonisk føring. Ledger Live er et projekt, der samler forskellige komponenter i én for at levere den bedste og mest sikre app til vores Nano-brugere, og det blev afspejlet i kodebasen.

De flows, vi havde på plads, var i bedste fald skæve, mest på grund af det faktum, at vi var 6 eller 7 udviklere for et par år siden. Da færre parter var involveret, var kommunikationen meget lettere, og vi slap af sted med det. Alligevel var der nogle smertepunkter i den måde, vi arbejdede på, især omkring udvikleroplevelsen og udgivelsesprocessen.

Dev Experience Flaskehalse

Afhængigheder

På grund af arten af ​​vores projekter arbejder vi på flere repositories på samme tid, med afhængigheder mellem dem. Her er et hurtigt overblik:

Ledger open source-bibliotekerne bruges af forretningslogikken, som derefter bruges af både desktop- og mobilapps. Men disse apps bruger også open source-biblioteker og bruger to forskellige versioner af det samme bibliotek (som @ledgerhq/errors for eksempel) ville ødelægge appen.

Vi var nødt til at støde versionen på den ene side, derefter udgive bibliotekerne (ja, til npm!!!), og derefter prøve igen, hvis det ikke virkede. Vi begyndte at stole på yalc til symlink-projekter, hvilket for det meste var okay, så længe vi ikke havde flere lag af afhængigheder (for eksempel fra open source-bibliotekerne til forretningslogikken og så fra forretningslogikken til apps). Vi forsøgte foreløbigt at arbejde med yarn link også, men det ser ud til, at det var dømt med React Native.

Test

Det var næsten umuligt at lave integrationstest med al den nyeste kode fra de forskellige projekter. Da vi skulle udgive bibliotekerne til registreringsdatabasen, var det et mareridt at teste alle komponenter med den seneste ajourførte kode

Vi skulle også vedligeholde flere CI med duplikeret logik.

Kontekstskift

Altid at flytte rundt på flere kodeeditorer / projekter / mapper fik udvikleroplevelsen til at se virkelig svag ud.

Frigivelse af flaskehalse i processen

Versionering

Det er svært at håndtere versionering af forskellige projekter, især når der er flere lag af afhængigheder.

Frigivelse

Udgivelsessporing var kompliceret på grund af det faktum, at projekterne var opdelt, og vi skulle styre udgivelserne af de forskellige projekter

Det var umuligt at automatisere udgivelsesprocessen, igen på grund af det faktum, at projekter var opdelt i forskellige repositories.

Og selvfølgelig var Kontinuerlig Levering utænkeligt på dette tidspunkt.

Mulig løsning?

Når man ser sig omkring efter inspiration, ser det ud til, at en mono-depotarkitektur er det centrale stykke, vi manglede. Det ville muliggøre en meget bedre udviklingsproces. Der er værktøjer bygget op omkring denne arkitektur, som vil hjælpe os med at opnå de manglende dele (frigivelse, automatisering, versionering...).

Men hvad er et monodepot?

I sin kerne er et mono-lager et projekt, der indkapsler alle andre relaterede projekter (applikationer, biblioteker, værktøjer) under én mappe/git-projekt. Det tillader bedre afhængighedsstyring, ensartethed af værktøjer (som kodestile og typescript-konfigurationer), centraliseret kontinuerlig integration, integrationstest, ensartet version af brugt pakket (reager for eksempel)...

Da det er et ret agnostisk system, var der nogle funktioner, som vi kunne finde og implementere. Forhåbentlig er der nogle fantastiske fællesskabsværktøjer, der kan hjælpe os med at tilføje orkestrering til builds (sekventielle builds, nyttige for CI), versionering, changelog-generering... som ville fuldføre det, vi manglede i vores udgivelsesproces.

ULEMPER

Mono repositories giver mening i en kontekst, hvor flere udviklere eller et team af udviklere arbejder på flere projekter på samme tid, med afhængigheder imellem dem. Det tilføjer dog et lag af kompleksitet under opsætningsfasen (især med allerede igangværende projekter, der har 4 års historie og aktiv udvikling). Værd at nævne, projektet bliver meget større (som meget større) med hensyn til diskplads. Alle projekter er nu under samme mappe og alle afhængigheder. Hvilke test er obligatoriske? Hvornår skal man udløse dem?

FORDELE

Efter at have evalueret tiden, omkostningerne og gennemførligheden af ​​vores ambitioner, var her nogle af de forventede fordele ved denne overgang:

• Forbedret afhængighedsstyring: Med en monorepo er det nemmere at styre afhængigheder mellem forskellige projekter, da de alle er gemt i det samme lager. Dette kan reducere behovet for løsninger som garnlink eller yalc, og gør det nemmere at sikre, at alle projekter bruger de korrekte versioner af afhængigheder.
• Bedre kodeorganisering: En monorepo kan gøre det nemmere at organisere kode, da alle projekter og deres afhængigheder er gemt i et enkelt lager. Det er nemmere at forstå, hvordan forskellige projekter passer sammen, og hvordan de afhænger af hinanden.
• Forbedret udvikleroplevelse: En monorepo kan gøre det lettere for udviklere at arbejde på flere projekter, da de ikke behøver at skifte mellem forskellige kodebaser eller repositories. Det kan også gøre det nemmere at køre integrationstests, da al koden er gemt i samme repository.
• Forbedret automatisering og kontinuerlig levering: Med en monorepo er det nemmere at automatisere opgaver som at bygge, teste og frigive kode. Dette kan være med til at strømline udgivelsesprocessen og gøre det nemmere at implementere kontinuerlig levering.
• Øget udviklingshastighed. Da forskellige teams arbejder i det samme lager, behøver de ikke vente til udgivelsen for at bekræfte resultatet, hvilket accelererer integrationen.

Konklusion

Samlet set kan implementeringen af ​​en monorepo-struktur hjælpe med at forbedre udviklingsprocessen, strømline udgivelsesprocessen og forbedre udvikleroplevelsen.

I de næste blogindlæg i denne serie vil vi lede dig igennem, hvordan dette store migrationsprojekt blev udført, de værktøjer, vi brugte, de valg, vi traf, resultatet og mere. Hold øje med del 2: Værktøjerne!

---

Valentin DE ALMEIDA
Developer Experience & Core Tech – Ledger Live

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
• PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
• PlatoESG. Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
• PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang her.
• Kilde: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain