Ledger Live Monorepo Project: Частина 1 – Проблематика (Make it Pain) | Леджер

У цій серії публікацій у блозі Валентин Де Алмейда, розробник Ledger Live, розповідає нам про еволюцію кодової бази Ledger Live протягом багатьох років. У цьому дописі в блозі ви дізнаєтесь, що спочатку він був заснований на кількох сховищах, проблеми, з якими ми зіткнулися на цьому шляху, і чому він мав еволюціонувати до архітектури монорепозиторію. У наступних публікаціях блогу ми пояснимо, як реалізовувався цей великий проект міграції. 

Трохи історії 

Зростання Ledger у 2020 та 2021 роках було значним. Ми агресивно набирали нових талантів, розширивши нашу команду від невеликої кількості до понад 20 розробників. Це означає, що багато нових інженерів було залучено до існуючих проектів. Оскільки наша команда швидко зростала, ми зіткнулися з новими проблемами, які нам довелося швидко вирішувати. Незважаючи на ці нові труднощі, ми залишалися зосередженими на нашій меті та продовжували виконувати виняткову роботу.

Ми зробили крок назад і розглянули нові проблеми, які виникають, коли до проекту приєднується все більше людей. Серед цих нових викликів можна назвати такі потреби:

• Простіші потоки.
• Кращі вказівки для вхідних і зовнішніх учасників.
• Уніфікований набір інструментів.
• Краще керування залежностями.
• Централізовані внески з відкритим кодом.

Сучасний стан: до міграції

Спочатку й до минулого року Ledger Live базувався на архітектурі полірепозиторію як для мобільних, так і для настільних інтерфейсів, а також усієї логіки, що стоїть за цим. Це не було свідоме рішення працювати таким чином, а лише результат розширення проекту без реального архітектурного керівництва. Ledger Live — це проект, який збирає різні компоненти в один, щоб забезпечити найкращу та найбезпечнішу програму для наших користувачів Nano, і це було відображено в кодовій базі.

Потоки, які ми мали, були в кращому випадку нестабільними, здебільшого через те, що пару років тому нас було 6 або 7 розробників. Оскільки було задіяно менше сторін, комунікація була значно легшою, і ми зійшли з рук. Тим не менш, у нашій роботі були деякі недоліки, особливо щодо досвіду розробників і процесу випуску.

Вузькі місця досвіду розробників

Залежності

Через характер наших проектів ми працюємо над кількома репозиторіями одночасно, із залежностями між ними. Ось короткий огляд:

Бібліотеки з відкритим кодом Ledger використовуються бізнес-логікою, яка потім використовується як настільними, так і мобільними додатками. Але ці програми також використовують бібліотеки з відкритим вихідним кодом і використовують дві різні версії однієї бібліотеки (наприклад @ledgerhq/errors наприклад) порушить роботу програми.

Нам потрібно було змінити версію з одного боку, потім опублікувати бібліотеки (так, у npm!!!), а потім спробувати ще раз, якщо це не спрацювало. Ми почали покладатися yalc до проектів символічних посилань, що в основному було нормально, доки ми не мали кількох рівнів залежностей (наприклад, від бібліотек з відкритим кодом до бізнес-логіки, а потім від бізнес-логіки до програм). Ми орієнтовно пробували працювати yarn link також, але, здається, це було приречено з React Native.

Тестування

Було майже неможливо провести інтеграційні тести з усім останнім кодом із різних проектів. Оскільки нам потрібно було опублікувати бібліотеки в реєстрі, тестування всіх компонентів за допомогою останнього оновленого коду було кошмаром

Нам також довелося підтримувати кілька КІ з дублюваною логікою.

Переключення контексту

Завжди переміщаючись між кількома редакторами коду / проектами / каталогами, досвід розробників виглядав дуже слабким.

Вузькі місця процесу випуску

Версіювання

Робота з керуванням версіями різних проектів є важкою, особливо коли є кілька рівнів залежностей.

Звільнення

Відстеження випусків було складним через те, що проекти були розділені, і нам доводилося керувати випусками різних проектів

Неможливо було автоматизувати процес випуску, знову ж таки через те, що проекти були розбиті на різні сховища.

І, звичайно, безперервна доставка була немислимою в цей момент.

Можливе рішення?

Озираючись навколо в пошуках натхнення, здається, що архітектура монорепозиторію є центральною частиною, якої нам бракувало. Це забезпечило б набагато кращий процес розвитку. Існують інструменти, побудовані навколо цієї архітектури, які допоможуть нам досягти відсутніх частин (випуск, автоматизація, версії…).

Але що таке монорепозиторій?

За своєю суттю монорепозиторій — це проект, який інкапсулює всі інші пов’язані проекти (додатки, бібліотеки, інструменти) в одній папці / проекті git. Це дозволяє краще керувати залежностями, уніфікувати інструменти (наприклад, стилі коду та конфігурації машинописів), централізовану безперервну інтеграцію, тестування інтеграції, уніфіковану версію використовуваного пакету (наприклад, React)…

Оскільки це досить агностична система, нам залишили деякі функції для виявлення та впровадження. Сподіваємось, є кілька чудових інструментів спільноти, які можуть допомогти нам додати оркестровку до збірок (послідовні збірки, корисні для CI), керування версіями, створення журналу змін.. що доповнить те, чого нам не вистачало в процесі випуску.

мінуси

Монорепозиторії мають сенс у контексті, коли кілька розробників або команда розробників працюють над кількома проектами одночасно, із залежностями між ними. Однак це додає деякий рівень складності на етапі налаштування (особливо з уже запущеними та запущеними проектами, які мають 4 роки історії та активного розвитку). Варто зазначити, що проект стає набагато більшим (начебто набагато більшим) з точки зору дискового простору. Усі проекти тепер знаходяться в одній папці та в усіх залежностях. Які тести є обов'язковими? Коли їх активувати?

профі

Оцінивши час, вартість і здійсненність наших амбіцій, ось деякі з очікуваних переваг цього переходу:

• Покращене керування залежностями: за допомогою монорепо легше керувати залежностями між різними проектами, оскільки всі вони зберігаються в одному сховищі. Це може зменшити потребу в обхідних шляхах, таких як yarn link або yalc, а також полегшити впевненість у тому, що всі проекти використовують правильні версії залежностей.
• Краща організація коду: монорепо може полегшити організацію коду, оскільки всі проекти та їхні залежності зберігаються в одному сховищі. Легше зрозуміти, як різні проекти поєднуються і як вони залежать один від одного.
• Покращений досвід розробника: монорепо може полегшити розробникам роботу над кількома проектами, оскільки їм не потрібно перемикатися між різними кодовими базами чи сховищами. Це також може спростити запуск інтеграційних тестів, оскільки весь код зберігається в одному репозиторії.
• Покращена автоматизація та безперервна доставка: за допомогою монорепо легше автоматизувати такі завдання, як створення, тестування та випуск коду. Це може допомогти оптимізувати процес випуску та спростити реалізацію безперервної доставки.
• Підвищена швидкість розвитку. Оскільки різні команди працюють в одному репозиторії, їм не потрібно чекати випуску, щоб перевірити результат, що прискорює інтеграцію.

Висновок

Загалом, впровадження структури монорепо може допомогти покращити процес розробки, оптимізувати процес випуску та покращити досвід розробника.

У наступних публікаціях у блозі цієї серії ми розповімо вам, як здійснювався цей великий проект міграції, інструменти, які ми використовували, вибір, який ми зробили, результат тощо. Слідкуйте за частиною 2: інструменти!

---

Валентин ДЕ АЛМЕЙДА
Досвід розробника та основні технології – Ledger Live

• Розповсюдження контенту та PR на основі SEO. Отримайте посилення сьогодні.
• PlatoData.Network Vertical Generative Ai. Додайте собі сили. Доступ тут.
• PlatoAiStream. Web3 Intelligence. Розширення знань. Доступ тут.
• ПлатонЕСГ. вуглець, CleanTech, Енергія, Навколишнє середовище, Сонячна, Поводження з відходами. Доступ тут.
• PlatoHealth. Розвідка про біотехнології та клінічні випробування. Доступ тут.
• джерело: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain