Ledger Live Monorepo Project: 1. del – Problematika (Make it Pain) | Ledger

V tej seriji objav v spletnem dnevniku nam Valentin De Almeida, razvijalec Ledger Live, govori o razvoju kodne baze Ledger Live skozi leta. V tej objavi v spletnem dnevniku boste izvedeli, da je sprva temeljil na več repozitorijih, na kakšne težave smo naleteli na poti in zakaj se je moral razviti v arhitekturo z eno repozitorijem. V naslednjih objavah na spletnem dnevniku bomo razložili, kako je potekal ta velik migracijski projekt. 

Malo zgodovine 

Ledgerjeva rast v letih 2020 in 2021 je bila pomembna. Agresivno smo zaposlovali nove talente in našo ekipo razširili s peščice na več kot 20 razvijalcev. To pomeni, da je bilo veliko novih inženirjev vključenih v obstoječe projekte. Ko je naša ekipa hitro rasla, smo naleteli na nove izzive, ki smo jih morali hitro rešiti. Kljub tem novim težavam smo ostali osredotočeni na naš cilj in še naprej opravljali izjemno delo.

Naredili smo korak nazaj in preučili nove težave, ki se pojavljajo, ko se vse več ljudi vključi v projekt. Med temi novimi izzivi lahko naštejemo naslednje potrebe:

• Preprostejši tokovi.
• Boljše smernice za prihajajoče in zunanje sodelavce.
• Enoten nabor orodij.
• Boljše upravljanje odvisnosti.
• Centralizirani odprtokodni prispevki.

Stanje tehnike: pred selitvijo

Sprva in vse do lani je Ledger Live temeljil na arhitekturi polirepozitorija za mobilne in namizne vmesnike, kot tudi vsa logika za tem. To ni bila zavestna odločitev za delo na ta način, ampak je bil le rezultat širitvenega projekta brez pravega arhitekturnega vodstva. Ledger Live je projekt, ki združuje različne komponente v eno, da našim uporabnikom Nano ponudi najboljšo in najvarnejšo aplikacijo, kar se je odrazilo v kodni bazi.

Tokovi, ki smo jih imeli, so bili v najboljšem primeru nestabilni, predvsem zaradi dejstva, da nas je bilo pred nekaj leti 6 ali 7 razvijalcev. Ker je bilo vključenih manj strank, je bila komunikacija veliko lažja in smo se izognili. Kljub temu je bilo v našem načinu dela nekaj bolečih točk, zlasti v zvezi z izkušnjo razvijalcev in postopkom izdaje.

Ozka grla pri izkušnjah razvijalcev

Odvisnosti

Zaradi narave naših projektov delamo na več repozitorijih hkrati, med katerimi so odvisnosti. Tukaj je kratek pregled:

Odprtokodne knjižnice Ledger uporablja poslovna logika, ki jo nato uporabljajo namizne in mobilne aplikacije. Toda te aplikacije uporabljajo tudi odprtokodne knjižnice in uporabljajo dve različni različici iste knjižnice (npr @ledgerhq/errors na primer) bi pokvaril aplikacijo.

Različico smo morali poenostaviti na eni strani, nato objaviti knjižnice (da, v npm!!!), nato poskusiti znova, če ni delovalo. Začeli smo se zanašati na yalc v projekte simbolnih povezav, kar je bilo večinoma v redu, dokler nismo imeli več plasti odvisnosti (na primer od odprtokodnih knjižnic do poslovne logike in nato od poslovne logike do aplikacij). Pogojno smo poskušali sodelovati z yarn link prav tako, vendar se zdi, da je bil z React Native obsojen na propad.

Testiranje

Skoraj nemogoče je bilo izvesti integracijske teste z najnovejšo kodo iz različnih projektov. Ker smo morali objaviti knjižnice v registru, je bilo testiranje vseh komponent z najnovejšo posodobljeno kodo nočna mora

Prav tako smo morali vzdrževati več CI s podvojeno logiko.

Preklop konteksta

Ker se vedno premikate po več urejevalnikih kode / projektih / imenikih, je bila izkušnja razvijalcev videti zelo šibka.

Ozka grla v procesu sprostitve

Različica

Ravnanje z različicami različnih projektov je težko, zlasti če obstaja več plasti odvisnosti.

Sproščanje

Sledenje izdajam je bilo zapleteno zaradi dejstva, da so bili projekti razdeljeni, zato smo morali upravljati izdaje različnih projektov

Postopek izdaje ni bilo mogoče avtomatizirati, spet zaradi dejstva, da so bili projekti razdeljeni v različna skladišča.

In seveda je bila neprekinjena dostava na tej točki nepredstavljiva.

Možna rešitev?

Če iščem navdih naokoli, se zdi, da je arhitektura mono repozitorija osrednji del, ki smo ga pogrešali. To bi omogočilo veliko boljši razvojni proces. Okoli te arhitekture so zgrajena orodja, ki bi nam pomagala doseči manjkajoče dele (izdaja, avtomatizacija, različice ...).

Toda kaj je mono repozitorij?

V svojem bistvu je mono repozitorij projekt, ki združuje vse druge povezane projekte (aplikacije, knjižnice, orodja) v eno mapo / projekt git. Omogoča boljše upravljanje odvisnosti, poenotenje orodij (kot so slogi kode in konfiguracije tipkopisov), centralizirano stalno integracijo, testiranje integracije, enotno različico uporabljenih paketov (na primer React)…

Ker gre za precej agnostičen sistem, smo nekatere funkcije pustili, da jih odkrijemo in implementiramo. Upajmo, da obstaja nekaj odličnih orodij skupnosti, ki bi nam lahko pomagala dodati orkestracijo v gradnje (zaporedne gradnje, uporabne za CI), različice, generiranje dnevnika sprememb..., ki bi dopolnila tisto, kar smo pogrešali v našem procesu izdaje.

Proti

Mono repozitoriji so smiselni v kontekstu, kjer več razvijalcev ali skupina razvijalcev dela na več projektih hkrati, med katerimi so odvisnosti. Vendar dodaja nekaj ravni kompleksnosti med fazo namestitve (zlasti pri projektih, ki že potekajo in imajo 4-letno zgodovino in aktivni razvoj). Omeniti velja, da projekt postane veliko večji (kot precej večji) v smislu prostora na disku. Vsi projekti so zdaj v isti mapi in vse odvisnosti. Kateri testi so obvezni? Kdaj jih sprožiti?

Prednosti

Po oceni časa, stroškov in izvedljivosti naših ambicij je nekaj pričakovanih koristi tega prehoda:

• Izboljšano upravljanje odvisnosti: Z monorepom je lažje upravljati odvisnosti med različnimi projekti, saj so vsi shranjeni v istem repozitoriju. To lahko zmanjša potrebo po rešitvah, kot je povezava preje ali yalcin olajšajte zagotavljanje, da vsi projekti uporabljajo pravilne različice odvisnosti.
• Boljša organizacija kode: monorepo lahko olajša organizacijo kode, saj so vsi projekti in njihove odvisnosti shranjeni v enem samem repozitoriju. Lažje je razumeti, kako se različni projekti ujemajo in kako so odvisni drug od drugega.
• Izboljšana razvijalska izkušnja: monorepo lahko razvijalcem olajša delo na več projektih, saj jim ni treba preklapljati med različnimi kodnimi bazami ali repozitoriji. Prav tako lahko olajša izvajanje integracijskih testov, saj je vsa koda shranjena v istem repozitoriju.
• Izboljšana avtomatizacija in neprekinjena dostava: Z monorepo je lažje avtomatizirati naloge, kot so izgradnja, testiranje in izdaja kode. To lahko pomaga poenostaviti postopek izdaje in olajša izvajanje neprekinjenega izvajanja.
• Povečana hitrost razvoja. Ker različne ekipe delajo v istem repozitoriju, jim ni treba čakati na izdajo, da preverijo rezultat, kar pospeši integracijo.

zaključek

Na splošno lahko implementacija strukture monorepo pomaga izboljšati razvojni proces, racionalizirati postopek izdaje in izboljšati izkušnjo razvijalcev.

V naslednjih objavah v spletnem dnevniku te serije vas bomo popeljali skozi to, kako je potekal ta velik projekt selitve, orodja, ki smo jih uporabili, odločitve, ki smo jih sprejeli, rezultat in drugo. Spremljajte nas za 2. del: Orodja!

---

Valentin DE ALMEIDA
Izkušnje razvijalcev in osnovna tehnologija – Ledger Live

• Distribucija vsebine in PR s pomočjo SEO. Okrepite se še danes.
• PlatoData.Network Vertical Generative Ai. Opolnomočite se. Dostopite tukaj.
• PlatoAiStream. Web3 Intelligence. Razširjeno znanje. Dostopite tukaj.
• PlatoESG. Ogljik, CleanTech, Energija, Okolje, sončna energija, Ravnanje z odpadki. Dostopite tukaj.
• PlatoHealth. Obveščanje o biotehnologiji in kliničnih preskušanjih. Dostopite tukaj.
• vir: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain