Разработка платформы HOQU — это комплексный проект. Перед командой разработчиков стоит задача создать в рамках платформы три приложения для трех различных типов пользователей. При этом, одни и те же части кода могут быть использованы повторно в разных приложениях. Возможность собирать приложения из имеющихся частей кода простым и понятным образом имеет большое влияние на скорость разработки платформы в целом.
В этой статье мы расскажем о том, как HOQU улучшает и ускоряет разработку презентационной части приложения с помощью хранения кода в одном месте (монорепозитории) и инструмента для работы с монорепозиториями на JavaScript, который называется Lerna.
Использование монорепозитория (монолитного репозитория) отличается от использования нескольких репозиториев тем, что в данном случае весь код находится в одном репозитории.
Репозиторий считается монолитным при выполнении следующих условий:
1) Репозиторий содержит более одного логического проекта.
2) Эти проекты могут быть не связаны, слабо связаны или связаны сторонними средствами (например, через систему управления зависимостями).
3) Репозиторий большой во многих смыслах:
- по количеству коммитов;
- по количеству веток и/или тегов;
- по количеству файлов;
- по размеру содержимого (то есть размеру папки).
Немалая доля написанного в ходе разработки кода может быть использована сразу для нескольких приложений, и, используя экосистему React (React — JavaScript-библиотека с открытым исходным кодом для разработки пользовательских интерфейсов), мы можем сделать приложения более модульными (собираемыми из частей кода). Мы переиспользуем не только интерфейс и части логики, но еще и целые страницы приложений. Предлагаем Вам рассмотреть это на примере пользовательского интерфейса HOQU и других некоторых страниц приложений.
Один из наиболее частых повторно используемых компонентов кода — кнопки, которые являются частью пользовательского интерфейса. Код, описывающий принцип работы кнопок, легко может быть использован при разработке любого из приложений.
Одним из наиболее сложных компонентов является меню, который широко используется во всех трех наших приложениях.
Между страницами Профиля аффилиата (веб-мастера) и рекламодателя расшаривается практически одинаковые для двух приложений презентация и логика.
Достаточно очевидно, что код пользовательского интерфейса расшаривается между всеми приложениями. Но более важным является то, что помимо этого, нам необходимо сделать возможным использование одних и тех же логики и презентации некоторых страниц для нескольких приложений, сохраняя при этом гибкость и скорость разработки.
Наиболее простым и очевидным решением этой задачи было использование npm link (npm — менеджер пакетов для JavaScript) или yarn workspaces (yarn это менеджер пакетов, который часто используется как замена npm, для работы с npm регистрами) и подключение основного пакета в приложения.
Это наиболее распространенный подход, используемый в случаях, когда речь идет о разработке приложений с одним и тем же основным пакетом, однако этот метод имеет свои недостатки:
- Версионирование приложений может закончиться путаницей и, в конечном итоге, станет трудно обеспечивать сопоставимость основного пакета для всех приложений из-за исправления багов и небольших отличий в приложениях для разных пользователей;
- Ведение разработки в 4х различных репозиториях рискует стать обременительным и медленным из-за необходимости переключения между репозиториями и запуска тестов вручную при изменении основного пакета.
Более комплексным решением, позволяющим использовать одни и те же компоненты кода в разных приложениях, является использование Lerna в совокупности с yarn workspaces. Следуя примеру крупных компаний, таких как Google, Facebook и Twitter, нами было принято решение использовать монорепозиторий.
Данный подход был протестирован нами когда мы были близки к завершению разработки бета-версии второго приложения. Мы поставили перед собой цель попытаться извлечь основной пакет, содержащий все данные, и создать два полностью модульных приложения за счет импортирования частей кода, которые могут быть использованы сразу для нескольких приложений, из основного пакета, сохраняя при этом все уникальные компоненты и значительные различия кода в пакете приложения.
Хотя переход к использованию монорепозитория не представлял собой слишком сложной задачи, потребовалось некоторое время для выделения основного пакета (например, для переименования вручную при импорте и ручного тестирования). Положительные стороны перехода к использованию монорепозитория стали очевидны сразу — мы избежали двух указанных выше недостатков, получив при этом следующие преимущества:
- Простая интеграция новых разработчиков в проект — достаточно ввести команду
lerna bootstrap, и все взаимосвязи будут установлены без необходимости запуска yarn install для всех проектов. Помимо этого, использование yarn workspaces позволяет экономить место, поскольку используется единая папка для node_modules при сборке проекта; - Все конфигурации линтера, тестов, сборки и развертывания всех наших приложений находятся в едином месте — в корневой папке. Все команды содержатся в директории
package.json, и Lerna позволяет запускать все сценарии параллельно, что, в свою очередь, экономит время при разработке и развертывании приложений.
Настройка CI (Continuous Integration) нашего проекта также не являлась сложной задачей, поскольку мы используем Gitlab CI, и все процессы развертывания наших приложений автоматизированы. Однако, в будущем с ростом нашего проекта, мы рассматриваем переход на более продвинутую версию, такую как Travis CI.
В заключение важно отметить, что хранение всего нашего кода в одном репозитории не означает, что наш код неделим и крепко переплетен между собой. Напротив, данный подход позволяет нам сделать код более модульным и легко переиспользуемым между приложениями.
С уважением,
Команда HOQU.
