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

I denne blogginnleggsserien forteller Valentin De Almeida, en Ledger Live-utvikler, oss gjennom Ledger Live-kodebase-utviklingen gjennom årene. I dette blogginnlegget vil du lære at det først var multi-repository-basert, problemene vi møtte underveis, og hvorfor det måtte utvikles til en mono-repository-arkitektur. I de neste blogginnleggene vil vi forklare hvordan dette store migrasjonsprosjektet ble gjennomført. 

Litt historie 

Ledgers vekst i 2020 og 2021 var betydelig. Vi rekrutterte aggressivt nytt talent, og utvidet teamet vårt fra bare en håndfull til over 20 utviklere. Dette betyr at mange nye ingeniører ble med på eksisterende prosjekter. Ettersom teamet vårt vokste raskt, møtte vi nye utfordringer som vi raskt måtte ta tak i. Til tross for disse nye vanskelighetene, forble vi fokusert på målet vårt og fortsatte å levere eksepsjonelt arbeid.

Vi tok et skritt tilbake og undersøkte de nye problematikkene som oppstår når flere og flere ble med på prosjektet. Blant disse nye utfordringene kan vi liste opp følgende behov:

• Enklere flyter.
• Bedre retningslinjer for innkommende og eksterne bidragsytere.
• Et enhetlig sett med verktøy.
• Bedre avhengighetshåndtering.
• Sentraliserte bidrag med åpen kildekode.

State of the Art: før migrasjonen

Opprinnelig, og inntil i fjor, var Ledger Live basert på en poly-repository-arkitektur, for både mobile og desktop front-ends, samt all logikken bak. Det var ikke en bevisst beslutning å jobbe på denne måten, men det var bare et resultat av et ekspanderende prosjekt uten noen reell arkitektonisk ledelse. Ledger Live er et prosjekt som samler ulike komponenter til én for å levere den beste og sikreste appen til våre Nano-brukere, og det ble reflektert i kodebasen.

Strømmene vi hadde på plass var i beste fall ustabile, mest på grunn av at vi var 6 eller 7 utviklere for et par år siden. Siden færre parter var involvert, var kommunikasjonen mye enklere, og vi slapp unna med det. Likevel var det noen smertepunkter i måten vi jobbet på, spesielt rundt utvikleropplevelsen og utgivelsesprosessen.

Dev Experience Flaskehalser

avhengig

På grunn av arten av prosjektene våre jobber vi på flere depoter samtidig, med avhengigheter mellom dem. Her er en rask oversikt:

Ledger åpen kildekode-bibliotekene brukes av forretningslogikken, som deretter brukes av både skrivebords- og mobilappene. Men disse appene bruker også åpen kildekode-bibliotekene, og bruker to forskjellige versjoner av det samme biblioteket (som @ledgerhq/errors for eksempel) ville ødelegge appen.

Vi trengte å bumpe versjonen på den ene siden, deretter publisere bibliotekene (ja, til npm!!!), og deretter prøve igjen hvis det ikke fungerte. Vi begynte å stole på yalc til symlink-prosjekter, noe som stort sett var greit så lenge vi ikke hadde flere lag med avhengigheter (for eksempel fra open source-bibliotekene til forretningslogikken, og deretter fra forretningslogikken til appene). Vi forsøkte forsøksvis å jobbe med yarn link også, men det ser ut til at det var dømt med React Native.

Testing

Det var nesten umulig å gjøre integrasjonstester med all den nyeste koden fra de forskjellige prosjektene. Siden vi trengte å publisere bibliotekene til registeret, var det et mareritt å teste alle komponenter med den siste oppdaterte koden

Vi måtte også vedlikeholde flere CI med duplisert logikk.

Kontekstbytte

Det å alltid flytte rundt på flere koderedigerere / prosjekter / kataloger fikk utvikleropplevelsen til å se veldig svak ut.

Frigjøringsprosess flaskehalser

versjons~~POS=TRUNC

Det er vanskelig å håndtere versjonering av forskjellige prosjekter, spesielt når det er flere lag med avhengigheter.

Releasing

Utgivelsessporing var komplisert på grunn av at prosjektene ble delt, og vi måtte administrere utgivelsene av de forskjellige prosjektene

Det var umulig å automatisere utgivelsesprosessen, igjen på grunn av det faktum at prosjekter ble delt opp i forskjellige depoter.

Og selvfølgelig var kontinuerlig levering utenkelig på dette tidspunktet.

Mulig løsning ?

Når vi ser rundt etter inspirasjon, ser det ut til at en monodepotarkitektur er den sentrale delen vi manglet. Det vil muliggjøre en mye bedre utviklingsprosess. Det er verktøy bygget rundt denne arkitekturen som vil hjelpe oss å oppnå de manglende delene (utgivelse, automatisering, versjonering ...).

Men hva er et monodepot?

I kjernen er et mono-repository et prosjekt som innkapsler alle andre relaterte prosjekter (applikasjoner, biblioteker, verktøy) under én mappe / git-prosjekt. Det tillater bedre avhengighetsstyring, uniformering av verktøy (som kodestiler og typescript-konfigurasjoner), sentralisert kontinuerlig integrasjon, integrasjonstesting, enhetlig versjon av brukt pakket (reager for eksempel)...

Siden det er et ganske agnostisk system, var noen funksjoner igjen for oss å oppdage og implementere. Forhåpentligvis er det noen flotte fellesskapsverktøy som kan hjelpe oss å legge til orkestrering til byggene (sekvensielle bygg, nyttig for CI), versjonering, endringslogggenerering... som ville fullføre det vi manglet i utgivelsesprosessen vår.

Ulemper

Mono repositories gir mening i en kontekst der flere utviklere, eller et team av utviklere jobber med flere prosjekter samtidig, med avhengigheter mellom dem. Det legger imidlertid til et lag med kompleksitet under oppsettfasen (spesielt med allerede oppegående prosjekter som har 4 års historie og aktiv utvikling). Verdt å nevne, prosjektet blir mye større (som mye større) når det gjelder diskplass. Alle prosjekter er nå under samme mappe og alle avhengigheter. Hvilke tester er obligatoriske? Når skal de utløses?

Pros

Etter å ha evaluert tiden, kostnadene og gjennomførbarheten av våre ambisjoner, var her noen av de forventede fordelene med denne overgangen:

• Forbedret avhengighetsstyring: Med en monorepo er det lettere å administrere avhengigheter mellom ulike prosjekter, siden de alle er lagret i samme depot. Dette kan redusere behovet for løsninger som garnlenke eller yalc, og gjør det enklere å sikre at alle prosjekter bruker de riktige versjonene av avhengigheter.
• Bedre kodeorganisering: En monorepo kan gjøre det enklere å organisere kode, ettersom alle prosjekter og deres avhengigheter er lagret i et enkelt depot. Det er lettere å forstå hvordan ulike prosjekter henger sammen og hvordan de er avhengige av hverandre.
• Forbedret utvikleropplevelse: En monorepo kan gjøre det lettere for utviklere å jobbe med flere prosjekter, siden de ikke trenger å bytte mellom forskjellige kodebaser eller depoter. Det kan også gjøre det enklere å kjøre integrasjonstester, da all koden er lagret i samme depot.
• Forbedret automatisering og kontinuerlig levering: Med en monorepo er det enklere å automatisere oppgaver som å bygge, teste og frigi kode. Dette kan bidra til å effektivisere utgivelsesprosessen og gjøre det enklere å implementere kontinuerlig levering.
• Økt utviklingshastighet. Siden forskjellige team jobber i samme depot, trenger de ikke å vente til utgivelsen for å bekrefte resultatet, noe som akselererer integrasjonen.

konklusjonen

Totalt sett kan implementeringen av en monorepo-struktur bidra til å forbedre utviklingsprosessen, strømlinjeforme utgivelsesprosessen og forbedre utvikleropplevelsen.

I de neste blogginnleggene i denne serien vil vi lede deg gjennom hvordan dette store migrasjonsprosjektet ble gjennomført, verktøyene vi brukte, valgene vi tok, resultatet og mer. Følg med på del 2: Verktøyene!

---

Valentin DE ALMEIDA
Utviklererfaring og kjerneteknologi – Ledger Live

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain