Progetto Ledger Live Monorepo: Parte 1 – Problemi (Make it Pain) | Registro

In questa serie di post sul blog, Valentin De Almeida, uno sviluppatore di Ledger Live, ci parla dell'evoluzione della base di codice di Ledger Live nel corso degli anni. In questo post del blog scoprirai che all'inizio era basato su più repository, i problemi che abbiamo riscontrato lungo il percorso e perché doveva evolversi verso un'architettura mono-repository. Nei prossimi post del blog spiegheremo come è stato condotto questo importante progetto di migrazione. 

Un po 'di storia 

La crescita di Ledger nel 2020 e nel 2021 è stata significativa. Abbiamo reclutato in modo aggressivo nuovi talenti, espandendo il nostro team da una manciata a oltre 20 sviluppatori. Ciò significa che molti nuovi ingegneri sono stati coinvolti nei progetti esistenti. Man mano che il nostro team cresceva rapidamente, abbiamo dovuto affrontare nuove sfide che abbiamo dovuto affrontare rapidamente. Nonostante queste nuove difficoltà, siamo rimasti concentrati sul nostro obiettivo e abbiamo continuato a svolgere un lavoro eccezionale.

Abbiamo fatto un passo indietro e abbiamo esaminato le nuove problematiche che sorgono quando sempre più persone vengono coinvolte nel progetto. Tra queste nuove sfide, possiamo elencare le seguenti esigenze:

• Flussi più semplici.
• Migliori linee guida per i contributori in entrata ed esterni.
• Un insieme unificato di strumenti.
• Migliore gestione delle dipendenze.
• Contributi open source centralizzati.

Stato dell'arte: prima della migrazione

Inizialmente, e fino all'anno scorso, Ledger Live si basava su un'architettura poly-repository, sia per il front-end mobile che per quello desktop, nonché su tutta la logica che sta dietro ad essa. Non è stata una decisione consapevole quella di lavorare in questa maniera, ma è stato solo il risultato di un progetto in espansione senza una vera e propria guida architettonica. Ledger Live è un progetto che riunisce vari componenti in uno solo per offrire l'app migliore e più sicura ai nostri utenti Nano e ciò si riflette nel codice base.

I flussi che avevamo in atto erano nella migliore delle ipotesi instabili, principalmente a causa del fatto che eravamo 6 o 7 sviluppatori un paio di anni fa. Poiché erano coinvolte meno parti, la comunicazione è stata molto più semplice e ce la siamo cavata. Tuttavia, c'erano alcuni punti critici nel modo in cui lavoravamo, in particolare riguardo all'esperienza dello sviluppatore e al processo di rilascio.

Colli di bottiglia dell'esperienza dello sviluppatore

dipendenze

A causa della natura dei nostri progetti, lavoriamo su più repository contemporaneamente, con dipendenze tra loro. Ecco una rapida panoramica:

Le librerie open source Ledger vengono utilizzate dalla logica aziendale, che viene quindi utilizzata sia dalle app desktop che da quelle mobili. Ma queste app utilizzano anche le librerie open source e utilizzano due diverse versioni della stessa libreria (come @ledgerhq/errors ad esempio) potrebbe danneggiare l'app.

Avevamo bisogno di eseguire il bumping della versione da un lato, quindi pubblicare le librerie (sì, su npm!!!), quindi riprovare se non funzionava. Abbiamo iniziato a fare affidamento yalc ai progetti di collegamento simbolico, il che andava bene fintanto che non avevamo diversi livelli di dipendenze (ad esempio, dalle librerie open source alla logica di business, e poi dalla logica di business alle app). Abbiamo provato provvisoriamente a lavorare con yarn link anche lui, ma sembra che sia stato condannato con React Native.

Testing

Era quasi impossibile eseguire test di integrazione con tutto il codice più recente dei diversi progetti. Dato che dovevamo pubblicare le librerie nel registro, testare tutti i componenti con il codice più aggiornato è stato un incubo

Dovevamo anche mantenere diversi CI con logica duplicata.

Cambio di contesto

Lo spostamento continuo tra diversi editor di codice/progetti/directory rendeva l'esperienza di sviluppo davvero debole.

Colli di bottiglia del processo di rilascio

versioning

Gestire il controllo delle versioni di diversi progetti è difficile, soprattutto quando sono presenti diversi livelli di dipendenze.

Rilasciando

Il monitoraggio dei rilasci era complicato a causa del fatto che i progetti erano divisi e dovevamo gestire i rilasci dei diversi progetti

Era impossibile automatizzare il processo di rilascio, sempre a causa del fatto che i progetti erano suddivisi in repository diversi.

E, naturalmente, la consegna continua era impensabile a questo punto.

Possibile soluzione ?

Cercando ispirazione, sembra che un'architettura mono repository sia il pezzo centrale che ci mancava. Ciò consentirebbe un processo di sviluppo molto migliore. Esistono strumenti costruiti attorno a questa architettura che ci aiuterebbero a realizzare le parti mancanti (rilascio, automazione, controllo delle versioni…).

Ma cos'è un repository mono?

Fondamentalmente, un repository mono è un progetto che incapsula tutti gli altri progetti correlati (applicazioni, librerie, strumenti) in un'unica cartella/progetto git. Consente una migliore gestione delle dipendenze, l'uniformizzazione degli strumenti (come stili di codice e configurazioni di typescript), integrazione continua centralizzata, test di integrazione, versione uniforme dei pacchetti utilizzati (react per esempio)...

Dato che si tratta di un sistema piuttosto agnostico, alcune funzionalità sono state lasciate a noi da scoprire e implementare. Si spera che ci siano alcuni ottimi strumenti della community che potrebbero aiutarci ad aggiungere orchestrazione alle build (build sequenziali, utili per CI), controllo delle versioni, generazione del registro delle modifiche... che completerebbero ciò che ci mancava nel nostro processo di rilascio.

Svantaggi

I repository mono hanno senso in un contesto in cui diversi sviluppatori, o un team di sviluppatori, lavorano su più progetti contemporaneamente, con dipendenze tra loro. Tuttavia, aggiunge un certo livello di complessità durante la fase di installazione (soprattutto con progetti già attivi e funzionanti che hanno 4 anni di storia e sviluppo attivo). Vale la pena menzionare che il progetto diventa molto più grande (o molto più grande) in termini di spazio su disco. Tutti i progetti sono ora nella stessa cartella e in tutte le dipendenze. Quali test sono obbligatori? Quando attivarli?

Vantaggi

Dopo aver valutato i tempi, i costi e la fattibilità delle nostre ambizioni, ecco alcuni dei vantaggi attesi da questa transizione:

• Gestione delle dipendenze migliorata: con un monorepo è più semplice gestire le dipendenze tra diversi progetti, poiché sono tutti archiviati nello stesso repository. Ciò può ridurre la necessità di soluzioni alternative come il collegamento del filato o yalce semplificare la garanzia che tutti i progetti utilizzino le versioni corrette delle dipendenze.
• Migliore organizzazione del codice: un monorepo può semplificare l'organizzazione del codice, poiché tutti i progetti e le relative dipendenze sono archiviati in un unico repository. È più facile capire come i diversi progetti si incastrano e come dipendono l'uno dall'altro.
• Esperienza di sviluppo migliorata: un monorepo può rendere più semplice per gli sviluppatori lavorare su più progetti, poiché non è necessario passare da una base di codice a un repository diversa. Può anche semplificare l'esecuzione dei test di integrazione, poiché tutto il codice è archiviato nello stesso repository.
• Automazione migliorata e distribuzione continua: con un monorepo è più semplice automatizzare attività come la creazione, il test e il rilascio del codice. Ciò può contribuire a semplificare il processo di rilascio e a semplificare l'implementazione della distribuzione continua.
• Maggiore velocità di sviluppo. Poiché diversi team lavorano nello stesso repository, non hanno bisogno di aspettare fino al rilascio per verificare il risultato, accelerando l'integrazione.

Conclusione

Nel complesso, l'implementazione di una struttura monorepo può contribuire a migliorare il processo di sviluppo, semplificare il processo di rilascio e migliorare l'esperienza dello sviluppatore.

Nei prossimi post del blog di questa serie, ti spiegheremo come è stato condotto questo importante progetto di migrazione, gli strumenti che abbiamo utilizzato, le scelte che abbiamo fatto, il risultato e altro ancora. Resta sintonizzato per la Parte 2: Gli strumenti!

---

Valentin DE ALMEIDA
Esperienza dello sviluppatore e tecnologia di base: Ledger Live

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• PlatoData.Network Generativo verticale Ai. Potenzia te stesso. Accedi qui.
• PlatoAiStream. Intelligenza Web3. Conoscenza amplificata. Accedi qui.
• PlatoneESG. Carbonio, Tecnologia pulita, Energia, Ambiente, Solare, Gestione dei rifiuti. Accedi qui.
• Platone Salute. Intelligence sulle biotecnologie e sulle sperimentazioni cliniche. Accedi qui.
• Fonte: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain