Projekt Ledger Live Monorepo: Część 1 – Problematyka (sprawia, że ​​boli) | Księga główna

W tej serii wpisów na blogu Valentin De Almeida, programista Ledger Live, opowiada nam o ewolucji bazy kodu Ledger Live na przestrzeni lat. W tym poście na blogu dowiesz się, że początkowo opierał się on na wielu repozytoriach, jakie problemy napotkaliśmy po drodze i dlaczego musiał ewoluować w kierunku architektury opartej na jednym repozytorium. W kolejnych wpisach na blogu wyjaśnimy, w jaki sposób przeprowadzono ten duży projekt migracyjny. 

Trochę historii 

Wzrost Ledgera w latach 2020 i 2021 był znaczący. Agresywnie rekrutowaliśmy nowe talenty, powiększając nasz zespół z kilku do ponad 20 programistów. Oznacza to, że do istniejących projektów dołączyło wielu nowych inżynierów. W miarę szybkiego powiększania się naszego zespołu, stanęliśmy przed nowymi wyzwaniami, którym musieliśmy szybko stawić czoła. Pomimo tych nowych trudności nadal skupialiśmy się na naszym celu i nadal zapewnialiśmy wyjątkową pracę.

Cofnęliśmy się o krok i przyjrzeliśmy się nowym problemom, które pojawiają się, gdy do projektu przyłącza się coraz więcej osób. Wśród nowych wyzwań możemy wymienić następujące potrzeby:

• Prostsze przepływy.
• Lepsze wytyczne dla autorów przychodzących i zewnętrznych.
• Ujednolicony zestaw narzędzi.
• Lepsze zarządzanie zależnościami.
• Scentralizowane wkłady open source.

Stan techniki: przed migracją

Początkowo, aż do zeszłego roku, Ledger Live opierał się na architekturze wielu repozytoriów, zarówno dla frontendów mobilnych, jak i stacjonarnych, wraz z całą logiką, która się za nią kryje. Nie była to świadoma decyzja o pracy w ten sposób, ale była to jedynie konsekwencja rozwijającego się projektu bez prawdziwego przewodnictwa architektonicznego. Ledger Live to projekt, który łączy różne komponenty w jeden, aby zapewnić najlepszą i najbezpieczniejszą aplikację użytkownikom Nano, co znalazło odzwierciedlenie w bazie kodu.

Przepływy, które mieliśmy, były w najlepszym wypadku niestabilne, głównie ze względu na fakt, że kilka lat temu mieliśmy 6 lub 7 programistów. Ponieważ zaangażowanych było mniej stron, komunikacja była znacznie łatwiejsza i uszło nam to na sucho. Mimo to w naszej pracy występowały pewne problemy, zwłaszcza związane z doświadczeniem programistów i procesem wydawania.

Wąskie gardła dla deweloperów

Zależności

Ze względu na charakter naszych projektów pracujemy na wielu repozytoriach jednocześnie, zachowując zależności pomiędzy nimi. Oto krótki przegląd:

Biblioteki open source Ledger są używane przez logikę biznesową, która jest następnie używana zarówno przez aplikacje komputerowe, jak i mobilne. Ale te aplikacje również korzystają z bibliotek open source i używają dwóch różnych wersji tej samej biblioteki (np @ledgerhq/errors na przykład) spowodowałoby uszkodzenie aplikacji.

Musieliśmy podbić wersję z jednej strony, następnie opublikować biblioteki (tak, do npm!!!), a następnie spróbować ponownie, jeśli to nie zadziałało. Zaczęliśmy na nich polegać yalc do projektów dowiązań symbolicznych, co było w większości w porządku, o ile nie mieliśmy kilku warstw zależności (na przykład od bibliotek open source do logiki biznesowej, a następnie od logiki biznesowej do aplikacji). Wstępnie próbowaliśmy nawiązać współpracę yarn link również, ale wygląda na to, że było to skazane na porażkę w przypadku React Native.

Testowanie

Przeprowadzenie testów integracyjnych z całym najnowszym kodem z różnych projektów było prawie niemożliwe. Ponieważ musieliśmy opublikować biblioteki w rejestrze, testowanie wszystkich komponentów przy użyciu najnowszego, aktualnego kodu było koszmarem

Musieliśmy także utrzymać kilka CI ze zduplikowaną logiką.

Przełączanie kontekstu

Ciągłe poruszanie się po kilku edytorach/projektach/katalogach kodu sprawiało, że doświadczenie programisty wyglądało naprawdę słabo.

Uwolnij wąskie gardła procesu

Wersja

Obsługa wersjonowania różnych projektów jest trudna, zwłaszcza gdy istnieje kilka warstw zależności.

Zwalnianie

Śledzenie wydań było skomplikowane ze względu na fakt, że projekty były podzielone i musieliśmy zarządzać wydaniami różnych projektów

Zautomatyzowanie procesu wydawania wersji było niemożliwe, ponownie ze względu na fakt, że projekty zostały podzielone na różne repozytoria.

I oczywiście ciągłe dostarczanie było w tym momencie nie do pomyślenia.

Możliwe rozwiązanie ?

Rozglądając się za inspiracją, wydaje się, że głównym elementem, którego nam brakowało, jest architektura pojedynczego repozytorium. Umożliwiłoby to znacznie lepszy proces rozwoju. Istnieją narzędzia zbudowane wokół tej architektury, które pomogłyby nam osiągnąć brakujące części (wydanie, automatyzacja, wersjonowanie…).

Ale czym jest repozytorium mono?

W swej istocie repozytorium mono to projekt, który hermetyzuje wszystkie inne powiązane projekty (aplikacje, biblioteki, narzędzia) w jednym folderze/projektie git. Umożliwia lepsze zarządzanie zależnościami, ujednolicenie narzędzi (takich jak style kodu i konfiguracje maszynopisu), scentralizowaną ciągłą integrację, testowanie integracji, ujednoliconą wersję używanych pakietów (na przykład React)…

Ponieważ jest to dość agnostyczny system, niektóre funkcje pozostawiono nam do odkrycia i wdrożenia. Mamy nadzieję, że istnieje kilka świetnych narzędzi społeczności, które pomogą nam w dodaniu orkiestracji do kompilacji (kompilacje sekwencyjne, pomocne dla CI), wersjonowaniu, generowaniu dziennika zmian... co uzupełniłoby to, czego brakowało nam w procesie wydawania.

Wady

Repozytoria mono mają sens w kontekście, w którym kilku programistów lub zespół programistów pracuje nad kilkoma projektami jednocześnie, zachowując zależności między nimi. Dodaje jednak pewną warstwę złożoności w fazie konfiguracji (szczególnie w przypadku już uruchomionych projektów, które mają 4-letnią historię i aktywny rozwój). Warto wspomnieć, że projekt staje się znacznie większy (na przykład znacznie większy) pod względem miejsca na dysku. Wszystkie projekty znajdują się teraz w tym samym folderze i wszystkie zależności. Które badania są obowiązkowe? Kiedy je wywołać?

ZALETY

Po dokonaniu oceny czasu, kosztów i wykonalności naszych ambicji, oto niektóre z oczekiwanych korzyści wynikających z tego przejścia:

• Ulepszone zarządzanie zależnościami: Dzięki monorepo łatwiej jest zarządzać zależnościami między różnymi projektami, ponieważ wszystkie są przechowywane w tym samym repozytorium. Może to zmniejszyć potrzebę stosowania obejść, takich jak połączenie przędzy lub yalci ułatwiają upewnienie się, że wszystkie projekty korzystają z poprawnych wersji zależności.
• Lepsza organizacja kodu: Monorepo może ułatwić organizację kodu, ponieważ wszystkie projekty i ich zależności są przechowywane w jednym repozytorium. Łatwiej jest zrozumieć, jak różne projekty pasują do siebie i jak od siebie zależą.
• Ulepszone doświadczenie programisty: Monorepo może ułatwić programistom pracę nad wieloma projektami, ponieważ nie muszą przełączać się między różnymi bazami kodu ani repozytoriami. Może to również ułatwić przeprowadzanie testów integracyjnych, ponieważ cały kod jest przechowywany w tym samym repozytorium.
• Ulepszona automatyzacja i ciągłe dostarczanie: dzięki monorepo łatwiej jest zautomatyzować zadania, takie jak tworzenie, testowanie i wydawanie kodu. Może to pomóc w usprawnieniu procesu wydawania i ułatwić wdrożenie ciągłego dostarczania.
• Zwiększona prędkość rozwoju. Ponieważ różne zespoły pracują w tym samym repozytorium, nie muszą czekać do wydania, aby zweryfikować wynik, co przyspiesza integrację.

Wnioski

Ogólnie rzecz biorąc, wdrożenie struktury monorepo może pomóc ulepszyć proces programowania, usprawnić proces wydawania i poprawić doświadczenie programisty.

W kolejnych wpisach na blogu z tej serii omówimy, w jaki sposób przeprowadzono ten duży projekt migracji, jakich narzędzi użyliśmy, dokonanych wyborów, wyników i nie tylko. Czekajcie na część 2: Narzędzia!

---

Valentina DE ALMEIDA
Doświadczenie programisty i podstawowa technologia – Ledger Live

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Platon Zdrowie. Inteligencja w zakresie biotechnologii i badań klinicznych. Dostęp tutaj.
• Źródło: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain