Ledger Live Monorepo-project: deel 1 – Problematiek (Make it Pain) | Grootboek

In deze serie blogposts vertelt Valentin De Almeida, een Ledger Live-ontwikkelaar, ons door de evolutie van de Ledger Live-codebase door de jaren heen. In deze blogpost leer je dat het aanvankelijk gebaseerd was op meerdere repository's, de problemen die we onderweg tegenkwamen en waarom het moest evolueren naar een mono-repository-architectuur. In de volgende blogposts leggen we uit hoe dit grote migratieproject werd uitgevoerd. 

Een beetje geschiedenis 

De groei van Ledger in 2020 en 2021 was aanzienlijk. We hebben op agressieve wijze nieuw talent geworven en ons team uitgebreid van slechts een handvol naar meer dan 20 ontwikkelaars. Dit betekent dat er veel nieuwe engineers zijn aangenomen bij bestaande projecten. Terwijl ons team snel groeide, kwamen we nieuwe uitdagingen tegen die we snel moesten aanpakken. Ondanks deze nieuwe moeilijkheden bleven we gefocust op ons doel en bleven we uitzonderlijk werk leveren.

We hebben een stapje terug gedaan en gekeken naar de nieuwe problemen die ontstaan ​​als steeds meer mensen zich bij het project aansluiten. Onder deze nieuwe uitdagingen kunnen we de volgende behoeften noemen:

• Eenvoudigere stromen.
• Betere richtlijnen voor inkomende en externe bijdragers.
• Een uniforme set tools.
• Beter afhankelijkheidsbeheer.
• Gecentraliseerde open source-bijdragen.

State of the Art: vóór de migratie

Aanvankelijk, en tot vorig jaar, was Ledger Live gebaseerd op een poly-repository-architectuur, voor zowel mobiele als desktop front-ends, evenals alle logica erachter. Het was geen bewuste keuze om op deze manier te werken, maar het was slechts het resultaat van een zich uitbreidend project zonder echte architectonische leiding. Ledger Live is een project dat verschillende componenten in één verzamelt om de beste en veiligste app aan onze Nano-gebruikers te leveren, en dit kwam tot uiting in de codebase.

De stromen die we hadden waren op zijn best wankel, vooral vanwege het feit dat we een paar jaar geleden met zes of zeven ontwikkelaars waren. Omdat er minder partijen bij betrokken waren, verliep de communicatie veel gemakkelijker en kwamen we ermee weg. Toch waren er enkele pijnpunten in de manier waarop we werkten, vooral rond de ontwikkelaarservaring en het releaseproces.

Knelpunten in de ontwikkelaarservaring

afhankelijkheden

Vanwege de aard van onze projecten werken we tegelijkertijd aan meerdere repositories, met onderlinge afhankelijkheden. Hier is een kort overzicht:

De open source-bibliotheken van Ledger worden gebruikt door de bedrijfslogica, die vervolgens wordt gebruikt door zowel de desktop- als mobiele apps. Maar die apps gebruiken ook de open source-bibliotheken en gebruiken twee verschillende versies van dezelfde bibliotheek (zoals @ledgerhq/errors bijvoorbeeld) zou de app kapot maken.

We moesten de versie aan de ene kant aanpassen, vervolgens de bibliotheken publiceren (ja, naar npm!!!), en het vervolgens opnieuw proberen als het niet werkte. We begonnen erop te vertrouwen yalc om projecten te symboliseren, wat meestal oké was, zolang we maar niet meerdere lagen van afhankelijkheden hadden (bijvoorbeeld van de open source-bibliotheken naar de bedrijfslogica, en vervolgens van bedrijfslogica naar de apps). We probeerden voorzichtig mee te werken yarn link ook, maar het lijkt erop dat het gedoemd was met React Native.

Testen

Het was vrijwel onmogelijk om integratietests uit te voeren met de nieuwste code van de verschillende projecten. Omdat we de bibliotheken in het register moesten publiceren, was het testen van alle componenten met de nieuwste code een nachtmerrie

We moesten ook verschillende CI's onderhouden met gedupliceerde logica.

Context wisselen

Het voortdurend verplaatsen van verschillende code-editors/projecten/mappen zorgde ervoor dat de dev-ervaring er erg zwak uitzag.

Laat procesknelpunten los

Versioning

Het omgaan met versiebeheer van verschillende projecten is moeilijk, vooral als er meerdere lagen van afhankelijkheden zijn.

Het loslaten van

Het volgen van releases was ingewikkeld vanwege het feit dat projecten waren opgesplitst en we de releases van de verschillende projecten moesten beheren

Het was onmogelijk om het releaseproces te automatiseren, opnieuw vanwege het feit dat projecten in verschillende repositories waren opgesplitst.

En natuurlijk was Continuous Delivery op dit moment ondenkbaar.

Mogelijke oplossing ?

Als we rondkijken voor inspiratie, lijkt het erop dat een monorepository-architectuur het centrale stuk is dat we misten. Het zou een veel beter ontwikkelingsproces mogelijk maken. Er zijn tools rond deze architectuur gebouwd die ons kunnen helpen de ontbrekende onderdelen te bereiken (release, automatisering, versiebeheer…).

Maar wat is een monorepository?

In de kern is een mono-repository een project dat alle andere gerelateerde projecten (applicaties, bibliotheken, tools) in één map / git-project samenvat. Het maakt beter afhankelijkheidsbeheer mogelijk, uniformisering van tools (zoals codestijlen en typoscriptconfiguraties), gecentraliseerde continue integratie, integratietests, uniforme versie van gebruikte pakketten (reageer bijvoorbeeld) ...

Omdat het een behoorlijk agnostisch systeem is, moesten we enkele functies ontdekken en implementeren. Hopelijk zijn er een aantal geweldige communitytools die ons kunnen helpen bij het toevoegen van orkestratie aan de builds (sequentiële builds, handig voor CI), versiebeheer, het genereren van changelogs ... wat zou completeren wat we misten in ons releaseproces.

NADELEN

Monorepository's zijn zinvol in een context waarin meerdere ontwikkelaars, of een team van ontwikkelaars tegelijkertijd aan verschillende projecten werken, met onderlinge afhankelijkheden. Het voegt echter een laagje complexiteit toe tijdens de opzetfase (vooral bij reeds lopende projecten met een geschiedenis van vier jaar en actieve ontwikkeling). Het vermelden waard is dat het project veel groter wordt (veel groter) in termen van schijfruimte. Alle projecten bevinden zich nu onder dezelfde map en alle afhankelijkheden. Welke testen zijn verplicht? Wanneer moet je ze activeren?

VOORDELEN

Na evaluatie van de tijd, de kosten en de haalbaarheid van onze ambities, waren hier enkele van de verwachte voordelen van deze transitie:

• Verbeterd afhankelijkheidsbeheer: Met een monorepo is het eenvoudiger om afhankelijkheden tussen verschillende projecten te beheren, omdat ze allemaal in dezelfde repository zijn opgeslagen. Dit kan de behoefte aan tijdelijke oplossingen zoals garenlink of yalcen maak het eenvoudiger om ervoor te zorgen dat alle projecten de juiste versies van afhankelijkheden gebruiken.
• Betere code-organisatie: Een monorepo kan het gemakkelijker maken om code te organiseren, omdat alle projecten en hun afhankelijkheden in één opslagplaats worden opgeslagen. Het is gemakkelijker om te begrijpen hoe verschillende projecten in elkaar passen en hoe ze van elkaar afhankelijk zijn.
• Verbeterde ontwikkelaarservaring: Een monorepo kan het voor ontwikkelaars gemakkelijker maken om aan meerdere projecten te werken, omdat ze niet hoeven te schakelen tussen verschillende codebases of repository's. Het kan het ook eenvoudiger maken om integratietests uit te voeren, omdat alle code in dezelfde repository wordt opgeslagen.
• Verbeterde automatisering en continue levering: Met een monorepo is het eenvoudiger om taken zoals het bouwen, testen en vrijgeven van code te automatiseren. Dit kan helpen het releaseproces te stroomlijnen en het eenvoudiger te maken om continue levering te implementeren.
• Verhoogde ontwikkelingssnelheid. Omdat verschillende teams in dezelfde repository werken, hoeven ze niet te wachten tot de release om het resultaat te verifiëren, waardoor de integratie wordt versneld.

Conclusie

Over het geheel genomen kan de implementatie van een monorepo-structuur helpen het ontwikkelingsproces te verbeteren, het releaseproces te stroomlijnen en de ontwikkelaarservaring te verbeteren.

In de volgende blogposts van deze serie laten we u zien hoe dit grote migratieproject werd uitgevoerd, de tools die we gebruikten, de keuzes die we maakten, het resultaat en meer. Blijf ons volgen voor deel 2: De tools!

---

Valentin DE ALMEIDA
Ontwikkelaarservaring en kerntechnologie – Ledger Live

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain