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

I den här blogginläggsserien berättar Valentin De Almeida, en Ledger Live-utvecklare, oss genom Ledger Live-kodbasutvecklingen genom åren. I det här blogginlägget kommer du att lära dig att det först var multi-repository-baserat, de problem vi stötte på på vägen och varför det behövde utvecklas till en mono-repository-arkitektur. I nästa blogginlägg kommer vi att förklara hur detta stora migrationsprojekt genomfördes. 

Lite historia 

Ledgers tillväxt under 2020 och 2021 var betydande. Vi rekryterade aggressivt nya talanger och utökade vårt team från bara en handfull till över 20 utvecklare. Detta innebär att många nya ingenjörer har tagits ombord på befintliga projekt. När vårt team snabbt växte mötte vi nya utmaningar som vi snabbt var tvungna att ta itu med. Trots dessa nya svårigheter förblev vi fokuserade på vårt mål och fortsatte att leverera exceptionellt arbete.

Vi tog ett steg tillbaka och tittade på den nya problematik som uppstår när fler och fler människor ansluter sig till projektet. Bland dessa nya utmaningar kan vi lista följande behov:

• Enklare flöden.
• Bättre riktlinjer för inkommande och externa bidragsgivare.
• En enhetlig uppsättning verktyg.
• Bättre beroendehantering.
• Centraliserade bidrag med öppen källkod.

State of Art: före migrationen

Till en början, och fram till förra året, baserades Ledger Live på en poly-repository-arkitektur, för både mobila och stationära front-ends, såväl som all logik bakom det. Det var inte ett medvetet beslut att arbeta på detta sätt, utan det var bara resultatet av ett expanderande projekt utan någon verklig arkitektonisk ledning. Ledger Live är ett projekt som samlar olika komponenter till en för att leverera den bästa och säkraste appen till våra Nano-användare, och det återspeglades i kodbasen.

Flödena vi hade på plats var i bästa fall fjällande, mest på grund av att vi var 6 eller 7 utvecklare för ett par år sedan. Eftersom färre parter var inblandade var kommunikationen mycket lättare och vi kom undan med det. Ändå fanns det några smärtpunkter i hur vi arbetade, särskilt kring utvecklarupplevelsen och releaseprocessen.

Dev Experience Flaskhalsar

beroenden

På grund av våra projekts natur arbetar vi på flera arkiv samtidigt, med beroenden mellan dem. Här är en snabb översikt:

Ledger-biblioteken med öppen källkod används av affärslogiken, som sedan används av både stationära och mobila appar. Men dessa appar använder också biblioteken med öppen källkod och använder två olika versioner av samma bibliotek (som @ledgerhq/errors till exempel) skulle bryta appen.

Vi behövde stöta versionen på ena sidan, sedan publicera biblioteken (ja, till npm!!!), och sedan försöka igen om det inte fungerade. Vi började lita på yalc till symlink-projekt, vilket för det mesta var okej så länge vi inte hade flera lager av beroenden (till exempel från biblioteken med öppen källkod till affärslogiken och sedan från affärslogiken till apparna). Vi försökte trevande arbeta med yarn link likaså, men det verkar vara dömt med React Native.

Testning

Det var nästan omöjligt att göra integrationstester med all den senaste koden från de olika projekten. Eftersom vi behövde publicera biblioteken till registret var det en mardröm att testa alla komponenter med den senaste uppdaterade koden

Vi var också tvungna att underhålla flera CI med duplicerad logik.

Kontextväxling

Att alltid flytta runt flera kodredigerare / projekt / kataloger fick utvecklarupplevelsen att se riktigt svag ut.

Flaskhalsar i processen

versionshantering

Att hantera versionshantering av olika projekt är svårt, särskilt när det finns flera lager av beroenden.

Släpper

Releasespårning var komplicerad på grund av att projekten delades upp, och vi var tvungna att hantera releaserna av de olika projekten

Det var omöjligt att automatisera releaseprocessen, återigen på grund av att projekt delades upp i olika arkiv.

Och naturligtvis var kontinuerlig leverans otänkbar vid denna tidpunkt.

Möjlig lösning ?

När vi tittar runt efter inspiration verkar det som om en monoförvarsarkitektur är den centrala biten vi saknade. Det skulle möjliggöra en mycket bättre utvecklingsprocess. Det finns verktyg byggda kring denna arkitektur som skulle hjälpa oss att uppnå de saknade delarna (release, automatisering, versionering...).

Men vad är ett monoförråd?

I sin kärna är ett mono-förråd ett projekt som kapslar in alla andra relaterade projekt (applikationer, bibliotek, verktyg) under en mapp/git-projekt. Det möjliggör bättre beroendehantering, enhetligisering av verktyg (som kodstilar och typskriptkonfigurationer), centraliserad kontinuerlig integration, integrationstestning, enhetlig version av använda paketerade (reagera till exempel)...

Eftersom det är ett ganska agnostiskt system, fanns det några funktioner kvar för oss att upptäcka och implementera. Förhoppningsvis finns det några bra community-verktyg som kan hjälpa oss att lägga till orkestrering till byggen (sekventiella byggnationer, användbara för CI), versionshantering, ändringslogggenerering... som skulle fullborda det vi saknade i vår releaseprocess.

Nackdelar

Mono repositories är vettigt i ett sammanhang där flera utvecklare, eller ett team av utvecklare arbetar med flera projekt samtidigt, med beroenden mellan dem. Det lägger dock till ett visst lager av komplexitet under installationsfasen (särskilt med redan igångsatta projekt som har 4 års historia och aktiv utveckling). Värt att nämna, projektet blir mycket större (som mycket större) när det gäller diskutrymme. Alla projekt ligger nu under samma mapp och alla beroenden. Vilka tester är obligatoriska? När ska man trigga dem?

Fördelar

Efter att ha utvärderat tiden, kostnaden och genomförbarheten av våra ambitioner, var här några av de förväntade fördelarna med denna övergång:

• Förbättrad beroendehantering: Med en monorepo är det lättare att hantera beroenden mellan olika projekt, eftersom de alla är lagrade i samma arkiv. Detta kan minska behovet av lösningar som garnlänk eller yalc, och gör det lättare att säkerställa att alla projekt använder rätt versioner av beroenden.
• Bättre kodorganisation: En monorepo kan göra det lättare att organisera kod, eftersom alla projekt och deras beroenden lagras i ett enda arkiv. Det är lättare att förstå hur olika projekt passar ihop och hur de är beroende av varandra.
• Förbättrad utvecklarupplevelse: En monorepo kan göra det lättare för utvecklare att arbeta med flera projekt, eftersom de inte behöver växla mellan olika kodbaser eller arkiv. Det kan också göra det enklare att köra integrationstester, eftersom all kod lagras i samma repository.
• Förbättrad automation och kontinuerlig leverans: Med en monorepo är det enklare att automatisera uppgifter som att bygga, testa och släppa kod. Detta kan hjälpa till att effektivisera releaseprocessen och göra det lättare att implementera kontinuerlig leverans.
• Ökad utvecklingshastighet. Eftersom olika team arbetar i samma arkiv, behöver de inte vänta tills releasen för att verifiera resultatet, vilket påskyndar integrationen.

Slutsats

Sammantaget kan implementeringen av en monorepo-struktur hjälpa till att förbättra utvecklingsprocessen, effektivisera releaseprocessen och förbättra utvecklarupplevelsen.

I nästa blogginlägg i den här serien kommer vi att gå igenom hur detta stora migreringsprojekt genomfördes, verktygen vi använde, valen vi gjorde, resultatet och mer. Håll utkik efter del 2: Verktygen!

---

Valentin DE ALMEIDA
Utvecklarerfarenhet & Core Tech – Ledger Live

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain