Proiect Ledger Live Monorepo: Partea 1 – Problematice (Make it Pain) | Registrul mare

În această serie de postări pe blog, Valentin De Almeida, un dezvoltator Ledger Live, ne vorbește despre evoluția bazei de cod Ledger Live de-a lungul anilor. În această postare pe blog, veți afla că la început a fost bazat pe mai multe depozite, problemele pe care le-am întâlnit pe parcurs și de ce trebuia să evolueze la o arhitectură mono-depozitare. În următoarele postări pe blog, vom explica cum a fost realizat acest proiect major de migrare. 

Un pic de istorie 

Creșterea Ledger în 2020 și 2021 a fost semnificativă. Am recrutat în mod agresiv noi talente, extinzându-ne echipa de la doar o mână la peste 20 de dezvoltatori. Aceasta înseamnă că mulți ingineri noi au fost incluși în proiectele existente. Pe măsură ce echipa noastră a crescut rapid, ne-am confruntat cu noi provocări pe care a trebuit să le rezolvăm rapid. În ciuda acestor noi dificultăți, am rămas concentrați asupra obiectivului nostru și am continuat să realizăm o muncă excepțională.

Am făcut un pas înapoi și am analizat noile probleme care apar atunci când tot mai mulți oameni s-au implicat în proiect. Printre aceste noi provocări, putem enumera următoarele nevoi:

• Fluxuri mai simple.
• Orientări mai bune pentru colaboratorii externi și veniți.
• Un set unificat de instrumente.
• Gestionare mai bună a dependenței.
• Contribuții centralizate open source.

Stadiul tehnicii: înainte de migrație

Inițial, și până anul trecut, Ledger Live s-a bazat pe o arhitectură poli-repository, atât pentru front-end-uri mobile, cât și pentru desktop, precum și pe toată logica din spatele acesteia. Nu a fost o decizie conștientă de a lucra în acest mod, ci a fost doar rezultatul unui proiect în expansiune, fără nicio conducere arhitecturală reală. Ledger Live este un proiect care adună diferite componente într-una singură pentru a oferi cea mai bună și mai sigură aplicație utilizatorilor noștri Nano și s-a reflectat în baza de cod.

Fluxurile pe care le-am avut în loc au fost în cel mai bun caz slab, mai ales din cauza faptului că eram 6 sau 7 dezvoltatori acum câțiva ani. Deoarece au fost implicate mai puține părți, comunicarea a fost mult mai ușoară și am scăpat cu totul. Totuși, au existat câteva puncte dure în modul în care lucram, în special în ceea ce privește experiența dezvoltatorului și procesul de lansare.

Blocajele experienței dezvoltatorilor

dependenţe

Datorită naturii proiectelor noastre, lucrăm pe mai multe depozite în același timp, cu dependențe între ele. Iată o scurtă prezentare generală:

Bibliotecile open source Ledger sunt folosite de logica de afaceri, care este apoi folosită atât de aplicațiile desktop, cât și de cele mobile. Dar acele aplicații folosesc, de asemenea, bibliotecile open source și folosesc două versiuni diferite ale aceleiași biblioteci (cum ar fi @ledgerhq/errors de exemplu) ar rupe aplicația.

Trebuia să aruncăm versiunea pe o parte, apoi să publicăm bibliotecile (da, la npm!!!), apoi să încercăm din nou dacă nu a funcționat. Am început să ne bazăm yalc la proiecte de legături simbolice, ceea ce era în mare parte ok atâta timp cât nu aveam mai multe straturi de dependențe (de exemplu, de la bibliotecile open source la logica de afaceri și apoi de la logica de afaceri la aplicații). Am încercat provizoriu să lucrăm cu yarn link de asemenea, dar se pare că a fost condamnat cu React Native.

Testarea

A fost aproape imposibil să faci teste de integrare cu tot cel mai recent cod din diferitele proiecte. Deoarece trebuia să publicăm bibliotecile în registru, testarea tuturor componentelor cu cel mai recent cod actualizat a fost un coșmar

De asemenea, a trebuit să menținem mai multe CI cu logica duplicată.

Comutarea contextului

Deplasarea mereu în jurul mai multor editori de cod/proiecte/directoare a făcut ca experiența dezvoltatorului să pară cu adevărat slabă.

Procesul de eliberare a blocajelor

Versionare

Gestionarea versiunilor diferitelor proiecte este dificilă, mai ales când există mai multe straturi de dependențe.

Eliberarea

Urmărirea lansărilor a fost complicată din cauza faptului că proiectele au fost împărțite și a trebuit să gestionăm lansările diferitelor proiecte

A fost imposibil de automatizat procesul de lansare, din nou din cauza faptului că proiectele au fost împărțite în depozite diferite.

Și, desigur, livrarea continuă era de neconceput în acest moment.

Soluție posibilă ?

Căutând în jur pentru inspirație, se pare că o arhitectură de depozit mono este piesa centrală care ne lipsea. Ar permite un proces de dezvoltare mult mai bun. Există instrumente construite în jurul acestei arhitecturi care ne-ar ajuta să obținem părțile lipsă (lansare, automatizare, versiunea…).

Dar, ce este un depozit mono?

În esență, un depozit mono este un proiect care încapsulează toate celelalte proiecte conexe (aplicații, biblioteci, instrumente) într-un singur folder / proiect git. Permite o mai bună gestionare a dependenței, uniformizarea instrumentelor (cum ar fi stilurile de cod și configurațiile dactilografiate), integrarea continuă centralizată, testarea integrării, versiunea uniformă a pachetelor utilizate (reacționează de exemplu)...

Deoarece este un sistem destul de agnostic, ni s-au lăsat câteva caracteristici să le descoperim și să le implementăm. Sperăm că există câteva instrumente excelente ale comunității care ne-ar putea ajuta să adăugăm orchestrare la build-uri (build-uri secvențiale, utile pentru CI), versiunea, generarea jurnalului de modificări... care ar completa ceea ce ne lipsea în procesul nostru de lansare.

Contra

Arhivele mono au sens într-un context în care mai mulți dezvoltatori sau o echipă de dezvoltatori lucrează la mai multe proiecte în același timp, cu dependențe între ei. Cu toate acestea, adaugă un anumit nivel de complexitate în timpul fazei de configurare (în special cu proiectele deja în funcțiune, care au 4 ani de istorie și dezvoltare activă). De menționat, proiectul devine mult mai mare (cum ar fi mult mai mare) în ceea ce privește spațiul pe disc. Toate proiectele sunt acum în același folder și toate dependențele. Ce teste sunt obligatorii? Când să le declanșăm?

Pro-uri

După ce am evaluat timpul, costul și fezabilitatea ambițiilor noastre, iată câteva dintre beneficiile așteptate ale acestei tranziții:

• Gestionare îmbunătățită a dependențelor: cu un monorepo, este mai ușor să gestionați dependențele dintre diferite proiecte, deoarece toate sunt stocate în același depozit. Acest lucru poate reduce nevoia de soluții cum ar fi link-ul de fire sau yalc, și ușurează asigurarea că toate proiectele folosesc versiunile corecte de dependențe.
• O organizare mai bună a codului: un monorepo poate facilita organizarea codului, deoarece toate proiectele și dependențele lor sunt stocate într-un singur depozit. Este mai ușor de înțeles cum se potrivesc diferite proiecte și cum depind unul de celălalt.
• Experiență îmbunătățită pentru dezvoltatori: un monorepo poate face mai ușor pentru dezvoltatori să lucreze la mai multe proiecte, deoarece nu trebuie să comute între diferite baze de cod sau depozite. De asemenea, poate facilita rularea testelor de integrare, deoarece tot codul este stocat în același depozit.
• Automatizare îmbunătățită și livrare continuă: cu un monorepo, este mai ușor să automatizați sarcini precum crearea, testarea și lansarea codului. Acest lucru poate ajuta la simplificarea procesului de lansare și la facilitarea implementării livrării continue.
• Viteza de dezvoltare crescută. Deoarece echipe diferite lucrează în același depozit, nu trebuie să aștepte până la lansare pentru a verifica rezultatul, accelerând integrarea.

Concluzie

În general, implementarea unei structuri monorepo poate ajuta la îmbunătățirea procesului de dezvoltare, la eficientizarea procesului de lansare și la îmbunătățirea experienței dezvoltatorului.

În următoarele postări pe blog ale acestei serii, vă vom prezenta modul în care a fost realizat acest proiect major de migrare, instrumentele pe care le-am folosit, alegerile pe care le-am făcut, rezultatul și multe altele. Rămâneți pe fază pentru partea 2: Instrumentele!

---

Valentin DE ALMEIDA
Experiență de dezvoltator și tehnologie de bază – Ledger Live

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• PlatoData.Network Vertical Generative Ai. Împuterniciți-vă. Accesați Aici.
• PlatoAiStream. Web3 Intelligence. Cunoștințe amplificate. Accesați Aici.
• PlatoESG. carbon, CleanTech, Energie, Mediu inconjurator, Solar, Managementul deșeurilor. Accesați Aici.
• PlatoHealth. Biotehnologie și Inteligență pentru studii clinice. Accesați Aici.
• Sursa: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain