Ledger Live Monorepo -projekti: Osa 1 – Ongelmat (Make it Pain) | Ledger

Tässä blogitekstisarjassa Valentin De Almeida, Ledger Live -kehittäjä, kertoo meille Ledger Live -koodikannan kehityksestä vuosien varrella. Tästä blogikirjoituksesta opit, että se perustui aluksi useaan tietovarastoon, mitä ongelmia matkan varrella kohtasimme ja miksi sen piti kehittyä yksivarastoarkkitehtuuriksi. Seuraavissa blogikirjoituksissa kerromme, kuinka tämä suuri muuttoliikeprojekti toteutettiin. 

Hieman historiaa 

Ledgerin kasvu vuosina 2020 ja 2021 oli merkittävää. Rekrytoimme aggressiivisesti uusia kykyjä ja laajensimme tiimimme vain kourallisesta yli 20 kehittäjäksi. Tämä tarkoittaa, että olemassa oleviin projekteihin otettiin mukaan paljon uusia insinöörejä. Kun tiimimme kasvoi nopeasti, kohtasimme uusia haasteita, joihin meidän oli vastattava nopeasti. Näistä uusista vaikeuksista huolimatta pysyimme keskittyneenä päämääräämme ja jatkoimme poikkeuksellisen työn tekemistä.

Otimme askeleen taaksepäin ja tarkastelimme uusia ongelmia, joita syntyy, kun yhä useammat ihmiset pääsivät mukaan projektiin. Näistä uusista haasteista voimme luetella seuraavat tarpeet:

• Yksinkertaisemmat virtaukset.
• Paremmat ohjeet saapuville ja ulkoisille osallistujille.
• Yhtenäinen työkalusarja.
• Parempi riippuvuuden hallinta.
• Keskitetyt avoimen lähdekoodin panokset.

Uusinta: ennen muuttoa

Aluksi ja viime vuoteen asti Ledger Live perustui monivarastoarkkitehtuuriin sekä mobiili- että työpöytäkäyttöliittymään sekä kaikkeen sen takana olevaan logiikkaan. Se ei ollut tietoinen päätös toimia tällä tavalla, vaan se oli vain tulos laajenevasta projektista ilman varsinaista arkkitehtonista johtoa. Ledger Live on projekti, joka kokoaa yhteen eri komponentteja tarjotakseen parhaan ja turvallisimman sovelluksen Nano-käyttäjillemme, ja se näkyi koodikannassa.

Käytössämme olleet virrat olivat parhaimmillaan epäselviä, lähinnä siitä syystä, että olimme 6 tai 7 kehittäjää pari vuotta sitten. Koska osallistujia oli vähemmän, kommunikointi oli paljon helpompaa ja selvisimme siitä. Silti työskentelyssämme oli joitain kipukohtia, erityisesti kehittäjäkokemuksen ja julkaisuprosessin suhteen.

Kehittäjäkokemuksen pullonkaulat

riippuvuudet

Projektidemme luonteesta johtuen työskentelemme useissa arkistoissa samanaikaisesti, ja niiden välillä on riippuvuuksia. Tässä on nopea yleiskatsaus:

Ledgerin avoimen lähdekoodin kirjastoja käyttää liiketoimintalogiikka, jota sitten käyttävät sekä työpöytä- että mobiilisovellukset. Mutta nämä sovellukset käyttävät myös avoimen lähdekoodin kirjastoja ja saman kirjaston kahta eri versiota (esim @ledgerhq/errors esimerkiksi) rikkoisi sovelluksen.

Meidän piti painaa versio toiselle puolelle, julkaista sitten kirjastot (kyllä, npm!!!) ja yrittää sitten uudelleen, jos se ei toimi. Aloimme luottaa yalc symlink-projekteihin, mikä oli enimmäkseen kunnossa niin kauan kuin meillä ei ollut useita riippuvuuksia (esimerkiksi avoimen lähdekoodin kirjastoista liiketoimintalogiikkaan ja sitten liiketoimintalogiikasta sovelluksiin). Yritimme alustavasti tehdä yhteistyötä yarn link samoin, mutta näyttää siltä, ​​​​että se oli tuomittu React Nativen kanssa.

Testaus

Oli lähes mahdotonta tehdä integraatiotestejä kaikella uusimmalla koodilla eri projekteista. Koska meidän piti julkaista kirjastot rekisteriin, kaikkien komponenttien testaaminen viimeisimmällä ajan tasalla koodilla oli painajainen

Jouduimme myös ylläpitämään useita CI:itä, joissa oli päällekkäinen logiikka.

Kontekstin vaihtaminen

Aina liikkuminen useiden koodieditorien / projektien / hakemistojen ympärillä sai kehittäjäkokemuksen näyttämään todella heikolta.

Vapauta prosessin pullonkaulat

versiointi

Erilaisten projektien versioinnin käsittely on vaikeaa, varsinkin jos riippuvuuksia on useita kerroksia.

Vapauttaminen

Julkaisujen seuranta oli monimutkaista johtuen siitä, että projektit jaettiin ja jouduimme hallitsemaan eri projektien julkaisuja

Julkaisuprosessia oli mahdotonta automatisoida, mikä taas johtui siitä, että projektit jaettiin eri tietovarastoihin.

Ja tietysti jatkuva toimitus oli mahdotonta ajatella tässä vaiheessa.

Mahdollinen ratkaisu ?

Inspiraatiota etsiessämme näyttää siltä, ​​että yksivärinen arkistoarkkitehtuuri on keskeinen osa, joka meiltä puuttui. Se mahdollistaisi paljon paremman kehitysprosessin. Tämän arkkitehtuurin ympärille on rakennettu työkaluja, jotka auttavat meitä saavuttamaan puuttuvat osat (julkaisu, automaatio, versiointi…).

Mutta mikä on mono-arkisto?

Pohjimmiltaan mono-arkisto on projekti, joka kiteyttää kaikki muut asiaan liittyvät projektit (sovellukset, kirjastot, työkalut) yhden kansion / git-projektin alle. Se mahdollistaa paremman riippuvuuden hallinnan, työkalujen yhtenäistämisen (kuten koodityylit ja konekirjoituskonfiguraatiot), keskitetyn jatkuvan integroinnin, integraatiotestauksen, yhtenäisen version käytetystä paketista (esim. reagoida)…

Koska se on melko agnostinen järjestelmä, jotkin ominaisuudet jätettiin meidän löydettäväksi ja toteutettaviksi. Toivottavasti on olemassa joitain hienoja yhteisötyökaluja, jotka voisivat auttaa meitä lisäämään koontiversioiden orkestrointia (peräkkäisiä koontiversioita, hyödyllistä CI:lle), versiointia, muutoslokien luomista... jotka täydentäisivät sen, mitä meiltä puuttui julkaisuprosessissamme.

MIINUKSET

Mono-arkistot ovat järkeviä tilanteessa, jossa useat kehittäjät tai kehittäjäryhmä työskentelee useissa projekteissa samanaikaisesti, ja niiden välillä on riippuvuuksia. Se kuitenkin lisää hieman monimutkaisuutta asennusvaiheessa (erityisesti jo käynnissä olevissa projekteissa, joilla on 4 vuoden historia ja aktiivinen kehitys). On syytä mainita, että projekti kasvaa paljon (kuten paljon isommaksi) levytilan suhteen. Kaikki projektit ovat nyt saman kansion ja riippuvuuksien alla. Mitkä testit ovat pakollisia? Milloin ne laukaistaan?

Plussat

Arvioituamme aikaa, kustannuksia ja tavoitteidemme toteutettavuutta, tässä oli joitain tämän siirtymän odotettuja etuja:

• Parannettu riippuvuuden hallinta: Monorepon avulla on helpompi hallita riippuvuuksia eri projektien välillä, koska ne kaikki on tallennettu samaan arkistoon. Tämä voi vähentää kiertotapojen tarvetta, kuten lankalinkki tai yalc, ja helpottaa sen varmistamista, että kaikki projektit käyttävät oikeita riippuvuuksien versioita.
• Parempi koodin organisointi: Monorepo voi helpottaa koodin järjestämistä, koska kaikki projektit ja niiden riippuvuudet on tallennettu yhteen arkistoon. On helpompi ymmärtää, miten eri projektit sopivat yhteen ja miten ne riippuvat toisistaan.
• Parempi kehittäjäkokemus: Monorepo voi helpottaa kehittäjien työskentelyä useiden projektien parissa, koska heidän ei tarvitse vaihtaa eri koodikantojen tai tietovarastojen välillä. Se voi myös helpottaa integraatiotestien suorittamista, koska kaikki koodi on tallennettu samaan arkistoon.
• Parannettu automaatio ja jatkuva toimitus: Monorepon avulla on helpompi automatisoida tehtäviä, kuten rakentaminen, testaus ja koodin julkaiseminen. Tämä voi auttaa virtaviivaistamaan julkaisuprosessia ja helpottamaan jatkuvan toimituksen toteuttamista.
• Lisääntynyt kehitysnopeus. Koska eri tiimit työskentelevät samassa arkistossa, niiden ei tarvitse odottaa julkaisuun asti varmistaakseen tuloksen, mikä nopeuttaa integraatiota.

Yhteenveto

Kaiken kaikkiaan monorepo-rakenteen käyttöönotto voi auttaa parantamaan kehitysprosessia, virtaviivaistamaan julkaisuprosessia ja parantamaan kehittäjäkokemusta.

Seuraavissa tämän sarjan blogikirjoituksissa opastamme sinut läpi kuinka tämä suuri migraatioprojekti toteutettiin, käyttämiämme työkalut, tekemämme valinnat, tulos ja paljon muuta. Pysy kuulolla osassa 2: Työkalut!

---

Valentin DE ALMEIDA
Kehittäjäkokemus ja ydintekniikka – Ledger Live

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• PlatoData.Network Vertical Generatiivinen Ai. Vahvista itseäsi. Pääsy tästä.
• PlatoAiStream. Web3 Intelligence. Tietoa laajennettu. Pääsy tästä.
• PlatoESG. hiili, CleanTech, energia, ympäristö, Aurinko, Jätehuolto. Pääsy tästä.
• PlatonHealth. Biotekniikan ja kliinisten kokeiden älykkyys. Pääsy tästä.
• Lähde: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain