Ledger Live Monorepo projekt: 1. osa – Probleemid (Make it Pain) | Pearaamat

Selles blogipostituste seerias räägib Ledger Live'i arendaja Valentin De Almeida meile Ledger Live'i koodibaasi arengust aastate jooksul. Sellest ajaveebipostitusest saate teada, et see oli alguses mitme hoidlapõhine, millised probleemid, millega me teel kokku puutusime, ja miks see pidi arenema ühehoidla arhitektuuriks. Järgmistes blogipostitustes selgitame, kuidas see suur rändeprojekt läbi viidi. 

Natuke ajaloost 

Ledgeri kasv aastatel 2020 ja 2021 oli märkimisväärne. Värbasime agressiivselt uusi talente, laiendades oma meeskonda vaid käputäielt enam kui 20 arendajani. See tähendab, et olemasolevatesse projektidesse kaasati palju uusi insenere. Kuna meie meeskond kasvas kiiresti, puutusime kokku uute väljakutsetega, millega pidime kiiresti tegelema. Nendest uutest raskustest hoolimata keskendusime oma eesmärgile ja jätkasime erakordse töö tegemist.

Astusime sammu tagasi ja uurisime uusi probleeme, mis tekivad, kui üha rohkem inimesi projektiga liitus. Nende uute väljakutsete hulgas võime loetleda järgmised vajadused:

• Lihtsamad voolud.
• Paremad juhised sissetulevatele ja välistele panustajatele.
• Ühtne tööriistade komplekt.
• Parem sõltuvuse juhtimine.
• Tsentraliseeritud avatud lähtekoodiga kaastööd.

Tehnika tase: enne migratsiooni

Esialgu ja kuni eelmise aastani põhines Ledger Live nii mobiilsete kui ka lauaarvutite esiotsadele mõeldud mitmehoidla arhitektuuril, samuti kogu selle taga oleval loogikal. See ei olnud teadlik otsus sellisel viisil töötada, vaid see oli ainult laieneva projekti tulemus, millel puudus tõeline arhitektuur. Ledger Live on projekt, mis koondab erinevad komponendid üheks, et pakkuda meie Nano kasutajatele parimat ja turvalisemat rakendust, ning see kajastus koodibaasis.

Need vood, mis meil olid, olid parimal juhul ebaühtlased, peamiselt seetõttu, et paar aastat tagasi olime 6 või 7 arendajat. Kuna osapooli oli vähem kaasatud, oli suhtlemine palju lihtsam ja saime hakkama. Siiski oli meie töös mõningaid valupunkte, eriti arendajakogemuse ja väljalaskeprotsessi osas.

Arenduskogemuse kitsaskohad

Sõltuvad

Projektide olemuse tõttu töötame korraga mitme hoidla kallal, kusjuures nende vahel on sõltuvused. Siin on kiire ülevaade:

Ledgeri avatud lähtekoodiga teeke kasutab äriloogika, mida seejärel kasutavad nii töölaua- kui ka mobiilirakendused. Kuid need rakendused kasutavad ka avatud lähtekoodiga teeke ja sama teegi kahte erinevat versiooni (nt @ledgerhq/errors näiteks) rikuks rakenduse.

Meil oli vaja versiooni ühel küljel kokku tõmmata, seejärel avaldada teegid (jah, npm-le!!!) ja seejärel uuesti proovida, kui see ei tööta. Hakkasime lootma yalc sümlinkiprojektidele, mis oli enamasti okei seni, kuni meil ei olnud mitut sõltuvuskihti (näiteks avatud lähtekoodiga teegidest äriloogikani ja seejärel äriloogikast rakendusteni). Proovisime esialgu koostööd teha yarn link samuti, kuid tundub, et see oli määratud React Native'iga.

Testimine

Erinevate projektide uusima koodiga integratsiooniteste oli peaaegu võimatu teha. Kuna meil oli vaja raamatukogud registris avaldada, oli kõigi komponentide testimine uusima ajakohase koodiga õudusunenägu.

Samuti pidime ülal pidama mitut dubleeritud loogikaga CI-d.

Konteksti vahetamine

Alati mitmes koodiredaktoris / projektis / kataloogis liikumine muutis arendaja kogemuse väga nõrgaks.

Protsessi kitsaskohtade vabastamine

Versioonide muutmine

Erinevate projektide versioonide haldamine on keeruline, eriti kui sõltuvusi on mitu kihti.

Vabastamine

Väljalasete jälgimine oli keeruline, kuna projektid olid jagatud ja meil tuli hallata erinevate projektide väljalaseid

Väljalaskeprotsessi oli võimatu automatiseerida, jällegi seetõttu, et projektid olid jagatud erinevatesse hoidlatesse.

Ja loomulikult oli pidev kohaletoimetamine praegusel hetkel mõeldamatu.

Võimalik lahendus?

Inspiratsiooni saamiseks ringi vaadates tundub, et monohoidla arhitektuur on keskne osa, millest me puudust tundsime. See võimaldaks palju paremat arendusprotsessi. Selle arhitektuuri ümber on üles ehitatud tööriistu, mis aitavad meil puuduvaid osi (väljalase, automatiseerimine, versioonide loomine jne) saavutada.

Aga mis on monohoidla?

Oma põhiolemuselt on monohoidla projekt, mis koondab kõik muud seotud projektid (rakendused, teegid, tööriistad) ühe kausta / git-projekti alla. See võimaldab paremat sõltuvuse haldamist, tööriistade ühtlustamist (nagu koodistiilid ja masinakirja konfiguratsioonid), tsentraliseeritud pidevat integreerimist, integratsiooni testimist, kasutatud pakettide ühtset versiooni (näiteks reageerida)…

Kuna tegemist on üsna agnostilise süsteemiga, jäeti mõned funktsioonid meie avastada ja rakendada. Loodetavasti on olemas mõned suurepärased kogukonna tööriistad, mis võivad aidata meil lisada järgudesse orkestreerimist (järjekorrajärgud, abiks CI jaoks), versioonide loomist, muudatuste logi genereerimist..., mis viiks lõpule selle, mis meil väljalaskeprotsessis puudu jäi.

Miinused

Monohoidlad on mõttekad kontekstis, kus mitu arendajat või arendajate meeskond töötab korraga mitme projekti kallal, kusjuures nende vahel on sõltuvused. Siiski lisab see seadistusfaasis teatud kihi keerukust (eriti juba töötavate projektide puhul, millel on 4 aastat ajalugu ja aktiivne arendus). Tasub mainida, et projekt muutub kettaruumi osas palju suuremaks (nagu palju suuremaks). Kõik projektid on nüüd sama kausta ja kõigi sõltuvuste all. Millised testid on kohustuslikud? Millal neid käivitada?

Plusse

Pärast aja, kulude ja meie ambitsioonide teostatavuse hindamist oli siin mõned selle ülemineku eeldatavad eelised.

• Täiustatud sõltuvushaldus: monorepoga on lihtsam hallata erinevate projektide vahelisi sõltuvusi, kuna need kõik on salvestatud samasse hoidlasse. See võib vähendada vajadust selliste lahenduste järele nagu lõngalink või yalc, ja hõlbustada selle tagamist, et kõik projektid kasutavad sõltuvuste õigeid versioone.
• Parem koodikorraldus: monorepo võib koodi korraldamist lihtsamaks muuta, kuna kõik projektid ja nende sõltuvused on salvestatud ühte hoidlasse. Lihtsam on aru saada, kuidas erinevad projektid omavahel kokku sobivad ja kuidas need üksteisest sõltuvad.
• Täiustatud arendajakogemus: monorepo võib hõlbustada arendajatel mitme projektiga töötamist, kuna neil ei ole vaja vahetada erinevate koodibaaside või hoidlate vahel. Samuti võib see hõlbustada integratsioonitestide käitamist, kuna kogu kood on salvestatud samasse hoidlasse.
• Täiustatud automatiseerimine ja pidev kohaletoimetamine: monorepoga on lihtsam automatiseerida selliseid toiminguid nagu koostamine, testimine ja koodi väljastamine. See võib aidata vabastamisprotsessi sujuvamaks muuta ja hõlbustada pidevat tarnimist.
• Suurenenud arengukiirus. Kuna samas hoidlas töötavad erinevad meeskonnad, ei pea nad tulemuse kontrollimiseks ootama väljalaskmist, mis kiirendab integreerimist.

Järeldus

Üldiselt võib monorepo-struktuuri rakendamine aidata täiustada arendusprotsessi, muuta väljalaskeprotsessi sujuvamaks ja täiustada arendaja kogemusi.

Selle sarja järgmistes blogipostitustes tutvustame teile, kuidas see suur migratsiooniprojekt läbi viidi, millised tööriistad kasutasime, millised valikud tegime, milline oli tulemus ja palju muud. Olge kursis 2. osaga: Tööriistad!

---

Valentin DE ALMEIDA
Arendaja kogemus ja põhitehnoloogia – Ledger Live

• SEO-põhise sisu ja PR-levi. Võimenduge juba täna.
• PlatoData.Network Vertikaalne generatiivne Ai. Jõustage ennast. Juurdepääs siia.
• PlatoAiStream. Web3 luure. Täiustatud teadmised. Juurdepääs siia.
• PlatoESG. Süsinik, CleanTech, Energia, Keskkond päikeseenergia, Jäätmekäitluse. Juurdepääs siia.
• PlatoTervis. Biotehnoloogia ja kliiniliste uuringute luureandmed. Juurdepääs siia.
• Allikas: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain