Ledger Live Monorepo Project: 1. rész – Probléma (Make it Pain) | Főkönyv

Ebben a blogbejegyzés-sorozatban Valentin De Almeida, a Ledger Live fejlesztője bemutatja nekünk a Ledger Live kódbázis évek során bekövetkezett fejlődését. Ebből a blogbejegyzésből megtudhatja, hogy eleinte több adattáron alapult, milyen problémákkal találkoztunk az út során, és hogy miért kellett egy tárolós architektúrává fejlődnie. A következő blogbejegyzésekben elmagyarázzuk, hogyan zajlott ez a nagy migrációs projekt. 

Egy kis történelem 

A Ledger növekedése 2020-ban és 2021-ben jelentős volt. Agresszíven toboroztunk új tehetségeket, így csapatunkat néhányról több mint 20 fejlesztőre bővítettük. Ez azt jelenti, hogy sok új mérnököt vontak be a meglévő projektekbe. Ahogy csapatunk gyorsan növekedett, új kihívások elé néztünk, amelyeket gyorsan meg kellett oldanunk. Az új nehézségek ellenére továbbra is a célunkra összpontosítottunk, és továbbra is kivételes munkát végeztünk.

Egy lépést hátráltunk, és megvizsgáltuk azokat az új problémákat, amelyek akkor merülnek fel, amikor egyre többen kapcsolódnak be a projektbe. Az új kihívások közül a következő igényeket sorolhatjuk fel:

• Egyszerűbb áramlások.
• Jobb iránymutatások a bejövő és külső közreműködők számára.
• Egységes eszközkészlet.
• Jobb függőségkezelés.
• Központosított nyílt forráskódú hozzájárulások.

A technika állása: a migráció előtt

Kezdetben – egészen tavalyig – a Ledger Live poli-repository architektúrán alapult, mind a mobil, mind az asztali front-endeknél, valamint a mögötte meghúzódó logikán. Nem tudatos döntés volt így dolgozni, hanem csak egy bővülő projekt eredménye, valódi építészeti vezetés nélkül. A Ledger Live egy olyan projekt, amely különböző összetevőket gyűjt össze, hogy a legjobb és legbiztonságosabb alkalmazást biztosítsa Nano-felhasználóinknak, és ez tükröződött a kódbázisban is.

A bevezetett áramlások a legjobb esetben is bizonytalanok voltak, főleg annak a ténynek köszönhetően, hogy néhány éve 6-7 fejlesztők voltunk. Mivel kevesebb párt vett részt, a kommunikáció sokkal könnyebb volt, és megúsztuk. Ennek ellenére volt néhány fájdalmas pont a munkánkban, különösen a fejlesztői tapasztalattal és a kiadási folyamattal kapcsolatban.

Fejlesztői tapasztalatok szűk keresztmetszetek

Dependencies

Projektjeink jellegéből adódóan egyszerre több adattáron dolgozunk, amelyek között vannak függőségek. Íme egy gyors áttekintés:

A Ledger nyílt forráskódú könyvtárait az üzleti logika használja, amelyet aztán az asztali és a mobilalkalmazások is használnak. De ezek az alkalmazások a nyílt forráskódú könyvtárakat is használják, és ugyanazon könyvtár két különböző verzióját (pl @ledgerhq/errors például) tönkretenné az alkalmazást.

A verziót az egyik oldalra kellett ütnünk, majd közzé kellett tenni a könyvtárakat (igen, npm-re!!!), majd próbáljuk újra, ha nem működne. Kezdtünk támaszkodni yalc a symlink projektekhez, ami többnyire rendben is volt, amíg nem volt több függőségi rétegünk (például a nyílt forráskódú könyvtáraktól az üzleti logikáig, majd az üzleti logikától az alkalmazásokig). Kísérletileg megpróbáltunk együtt dolgozni yarn link is, de úgy tűnik, ez a React Native-vel volt kudarcra ítélve.

Tesztelés

Szinte lehetetlen volt integrációs teszteket végrehajtani a különböző projektek legújabb kódjával. Mivel a könyvtárakat közzé kellett tennünk a rendszerleíró adatbázisban, rémálom volt az összes összetevőt a legfrissebb kóddal tesztelni.

Több CI-t is fenn kellett tartanunk duplikált logikával.

Környezetváltás

Ha mindig több kódszerkesztőben/projektben/könyvtárban mozogtunk, a fejlesztői élmény nagyon gyengének tűnt.

A folyamat szűk keresztmetszete felszabadítása

Versioning

A különböző projektek verziószámának kezelése nehéz, különösen akkor, ha több függőségi rétegről van szó.

Felszabadító

A kiadáskövetés bonyolult volt a projektek felosztása miatt, és a különböző projektek kiadásait kellett kezelnünk.

Lehetetlen volt automatizálni a kiadási folyamatot, ami szintén annak a ténynek köszönhető, hogy a projektek különböző tárolókra voltak felosztva.

És természetesen a Folyamatos Szállítás ezen a ponton elképzelhetetlen volt.

Lehetséges megoldás ?

Ha inspirációt keresünk, úgy tűnik, hogy a mono tároló architektúra a központi elem, ami hiányzott. Sokkal jobb fejlesztési folyamatot tesz lehetővé. Az architektúra köré olyan eszközöket építettek, amelyek segítenek elérni a hiányzó részeket (kiadás, automatizálás, verziókezelés…).

De mi az a mono adattár?

Lényegében a mono adattár egy olyan projekt, amely az összes többi kapcsolódó projektet (alkalmazásokat, könyvtárakat, eszközöket) egyetlen mappa/git projekt alá foglalja. Lehetővé teszi a jobb függőségkezelést, az eszközök egységesítését (mint például a kódstílusok és a gépírási konfigurációk), a központosított folyamatos integrációt, az integrációs tesztelést, a használt csomagok egységes verzióját (például reagálni)…

Mivel ez egy meglehetősen agnosztikus rendszer, néhány funkciót ránk hagytak felfedezni és megvalósítani. Remélhetőleg van néhány nagyszerű közösségi eszköz, amelyek segíthetnek nekünk hangszerelést hozzáadni a buildekhez (szekvenciális buildek, hasznosak a CI-hez), verziószámítást, változásnapló generálást… amelyek kiegészítik azt, amit a kiadási folyamatunkból hiányoltunk.

Hátrányok

A mono adattárak értelmesek olyan környezetben, ahol több fejlesztő vagy egy fejlesztői csapat dolgozik egyszerre több projekten, köztük függőséggel. Mindazonáltal a beállítási szakaszban némi összetettséget ad hozzá (különösen a már működő és futó projekteknél, amelyek 4 éves múlttal és aktív fejlesztéssel rendelkeznek). Érdemes megemlíteni, hogy a projekt sokkal nagyobb lesz (például sokkal nagyobb) a lemezterületet tekintve. Az összes projekt ugyanabban a mappában és minden függőség alatt található. Mely vizsgálatok kötelezőek? Mikor kell kiváltani őket?

Érvek

Az idő, a költségek és ambícióink megvalósíthatóságának értékelése után az átállás várható előnyei közül néhány:

• Továbbfejlesztett függőségek kezelése: A monorepo használatával könnyebb a különböző projektek közötti függőségek kezelése, mivel mindegyik ugyanabban a tárolóban van tárolva. Ez csökkentheti az olyan megoldások szükségességét, mint a fonallink vagy yalc, és megkönnyíti annak biztosítását, hogy minden projekt a függőségek megfelelő verzióit használja.
• Jobb kódszervezés: A monorepo megkönnyítheti a kód rendszerezését, mivel az összes projektet és azok függőségeit egyetlen tárolóban tárolják. Könnyebb megérteni, hogy a különböző projektek hogyan illeszkednek egymáshoz, és hogyan függenek egymástól.
• Továbbfejlesztett fejlesztői élmény: A monorepo megkönnyítheti a fejlesztők számára, hogy több projekten dolgozzanak, mivel nem kell váltaniuk a különböző kódbázisok vagy adattárak között. Az integrációs tesztek futtatását is megkönnyítheti, mivel az összes kód ugyanabban a tárolóban van tárolva.
• Továbbfejlesztett automatizálás és folyamatos kézbesítés: A monorepo segítségével könnyebben automatizálhatók az olyan feladatok, mint az építés, a tesztelés és a kód kiadása. Ez elősegítheti a kiadási folyamat egyszerűsítését és megkönnyítheti a folyamatos szállítás megvalósítását.
• Megnövelt fejlesztési sebesség. Mivel a különböző csapatok ugyanabban a tárolóban dolgoznak, nem kell várniuk a kiadásig az eredmény ellenőrzésével, ami felgyorsítja az integrációt.

Következtetés

Összességében a monorepo struktúra megvalósítása segíthet a fejlesztési folyamat javításában, a kiadási folyamat egyszerűsítésében és a fejlesztői élmény javításában.

A sorozat következő blogbejegyzéseiben végigvezetjük Önt, hogyan zajlott ez a nagy migrációs projekt, milyen eszközöket használtunk, milyen döntéseket hoztunk, milyen eredményt hoztunk és egyebeket. Maradjon velünk a 2. rész: Az eszközök!

---

Valentin DE ALMEIDA
Fejlesztői tapasztalat és alaptechnológia – Ledger Live

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• PlatoData.Network Vertical Generative Ai. Erősítse meg magát. Hozzáférés itt.
• PlatoAiStream. Web3 Intelligence. Felerősített tudás. Hozzáférés itt.
• PlatoESG. Carbon, CleanTech, Energia, Környezet, Nap, Hulladékgazdálkodás. Hozzáférés itt.
• PlatoHealth. Biotechnológiai és klinikai vizsgálatok intelligencia. Hozzáférés itt.
• Forrás: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain