Проект Ledger Live Monorepo: Часть 1 – Проблематика (причинить боль) | Леджер

В этой серии публикаций в блоге Валентин Де Алмейда, разработчик Ledger Live, рассказывает нам об эволюции кодовой базы Ledger Live на протяжении многих лет. Из этого поста в блоге вы узнаете, что сначала он был основан на нескольких репозиториях, о проблемах, с которыми мы столкнулись на этом пути, и о том, почему необходимо было перейти к архитектуре с одним репозиторием. В следующих сообщениях блога мы объясним, как осуществлялся этот крупный проект миграции. 

Немного истории 

Рост Ledger в 2020 и 2021 годах был значительным. Мы активно набирали новые таланты, расширив нашу команду с нескольких до более чем 20 разработчиков. Это означает, что к существующим проектам было привлечено много новых инженеров. Поскольку наша команда быстро росла, мы столкнулись с новыми проблемами, которые нам пришлось быстро решать. Несмотря на эти новые трудности, мы оставались сосредоточенными на нашей цели и продолжали выполнять исключительную работу.

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

• Более простые потоки.
• Лучшие рекомендации для новых и внешних участников.
• Единый набор инструментов.
• Лучшее управление зависимостями.
• Централизованный вклад с открытым исходным кодом.

Состояние дел: до миграции

Первоначально и до прошлого года Ledger Live основывался на полирепозиториевой архитектуре как для мобильных, так и для настольных компьютеров, а также всей лежащей в ее основе логике. Работать таким образом не было сознательным решением, а лишь результатом расширяющегося проекта без реального архитектурного руководства. Ledger Live — это проект, который объединяет различные компоненты в один, чтобы предоставить нашим пользователям Nano самое лучшее и безопасное приложение, и это было отражено в базе кода.

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

Узкие места в опыте разработки

Зависимости

Из-за характера наших проектов мы одновременно работаем с несколькими репозиториями, между которыми существуют зависимости. Вот краткий обзор:

Библиотеки с открытым исходным кодом Ledger используются бизнес-логикой, которая затем используется как настольными, так и мобильными приложениями. Но эти приложения также используют библиотеки с открытым исходным кодом и используют две разные версии одной и той же библиотеки (например, @ledgerhq/errors например) сломает приложение.

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

Тестирование

Было практически невозможно провести интеграционные тесты со всем последним кодом из разных проектов. Поскольку нам нужно было опубликовать библиотеки в реестре, тестирование всех компонентов с использованием последней версии кода было кошмаром.

Нам также пришлось поддерживать несколько CI с дублированной логикой.

Переключение контекста

Постоянное перемещение по нескольким редакторам кода/проектам/каталогам делало процесс разработки очень слабым.

Узкие места процесса выпуска

Versioning

Управление версиями различных проектов затруднено, особенно если существует несколько уровней зависимостей.

Отпустив

Отслеживание релизов было затруднено из-за того, что проекты были разделены, и нам приходилось управлять релизами разных проектов.

Автоматизировать процесс релиза было невозможно, опять же из-за того, что проекты были разбиты по разным репозиториям.

И, конечно же, непрерывная доставка на тот момент была немыслима.

Возможное решение ?

Если поискать вдохновение, то кажется, что архитектура монорепозитория — это центральная часть, которой нам не хватало. Это позволит значительно улучшить процесс разработки. На основе этой архитектуры созданы инструменты, которые помогут нам достичь недостающих частей (релиз, автоматизация, управление версиями…).

Но что такое монорепозиторий?

По своей сути монорепозиторий — это проект, который инкапсулирует все остальные связанные проекты (приложения, библиотеки, инструменты) в одну папку/проект git. Это позволяет лучше управлять зависимостями, унифицировать инструменты (такие как стили кода и конфигурации машинописных сценариев), централизованную непрерывную интеграцию, интеграционное тестирование, унифицированную версию используемых пакетов (например, React)…

Поскольку это довольно независимая система, нам осталось обнаружить и реализовать некоторые функции. Надеемся, что есть несколько отличных инструментов сообщества, которые помогут нам добавить оркестровку к сборкам (последовательные сборки, полезны для CI), управление версиями, создание журнала изменений... которые дополнят то, чего нам не хватало в процессе выпуска.

Минусы

Моно-репозитории имеют смысл в контексте, когда несколько разработчиков или группа разработчиков одновременно работают над несколькими проектами, между которыми существуют зависимости. Однако это добавляет некоторый уровень сложности на этапе установки (особенно с уже запущенными проектами, имеющими 4-летнюю историю и активную разработку). Стоит отметить, что проект становится намного больше (точнее, намного больше) с точки зрения дискового пространства. Все проекты теперь находятся в одной папке и со всеми зависимостями. Какие анализы являются обязательными? Когда их запускать?

Плюсы

После оценки времени, стоимости и осуществимости наших амбиций, вот некоторые ожидаемые преимущества этого перехода:

• Улучшенное управление зависимостями: с помощью монорепозитория проще управлять зависимостями между различными проектами, поскольку все они хранятся в одном репозитории. Это может уменьшить потребность в обходных путях, таких как ссылка пряжи или yalcи упростить проверку того, что все проекты используют правильные версии зависимостей.
• Лучшая организация кода: монорепозиторий может упростить организацию кода, поскольку все проекты и их зависимости хранятся в одном репозитории. Так легче понять, как разные проекты сочетаются друг с другом и как они зависят друг от друга.
• Улучшенный опыт разработки: монорепозиторий может облегчить разработчикам работу над несколькими проектами, поскольку им не нужно переключаться между разными базами кода или репозиториями. Это также может упростить запуск интеграционных тестов, поскольку весь код хранится в одном репозитории.
• Улучшенная автоматизация и непрерывная доставка. Благодаря монорепозиторию проще автоматизировать такие задачи, как сборка, тестирование и выпуск кода. Это может помочь оптимизировать процесс выпуска и упростить реализацию непрерывной доставки.
• Увеличена скорость разработки. Поскольку разные команды работают в одном репозитории, им не нужно ждать релиза, чтобы проверить результат, что ускоряет интеграцию.

Заключение

В целом, реализация структуры монорепозитория может помочь улучшить процесс разработки, упростить процесс выпуска и улучшить качество работы разработчиков.

В следующих публикациях этой серии мы расскажем вам, как проводился этот крупный проект миграции, какие инструменты мы использовали, какой выбор мы сделали, какие результаты и многое другое. Оставайтесь с нами, чтобы увидеть Часть 2: Инструменты!

---

Валентин ДЕ АЛМЕЙДА
Опыт разработчиков и основные технологии – Ledger Live

• SEO-контент и PR-распределение. Получите усиление сегодня.
• PlatoData.Network Вертикальный генеративный ИИ. Расширьте возможности себя. Доступ здесь.
• ПлатонАйСтрим. Интеллект Web3. Расширение знаний. Доступ здесь.
• ПлатонЭСГ. Углерод, чистые технологии, Энергия, Окружающая среда, Солнечная, Управление отходами. Доступ здесь.
• ПлатонЗдоровье. Биотехнологии и клинические исследования. Доступ здесь.
• Источник: https://www.ledger.com/blog/ledger-live-monorepo-project-part-1-problematics-make-it-pain