Исследование того, как мы можем хранить код и обмениваться функциями, службами и конфигурацией между развернутыми приложениями, чтобы поддерживать стандарты и экономить время.
Представьте, что мы работаем над новым проектом, одним из требований которого является разбиение большого и устаревшего монолитного приложения на микросервисы и новый пользовательский интерфейс — вы знаете, как это делается :)
Цель состоит в том, чтобы разделить текущий монолит на множество небольших веб-приложений с меньшими обязанностями, которые будут использовать новую микросервисную архитектуру для хранения данных.
Начнем с нескольких вопросов
- Какие проблемы в организации решит Monorepo?
- Не приведет ли хранение всего кода в одном месте, а не в отдельных репозиториях, к ненужным ограничениям?
- Должен ли внешний и внутренний код находиться в одном репозитории кода?
- Организационная структура/иерархия настроена таким образом, что это может привести к конфликту в подходе к общим функциям?
- Нужно ли делиться кодом и кем он будет использоваться?
- Должен ли код быть как можно ближе к своему потребителю и следует ли добавлять дополнительные абстракции, когда это единственный вариант?
NB: я даю некоторые мнения, основанные на том, что мы сделали в конце
Соображения
Чтобы помочь ответить на вопросы, давайте рассмотрим несколько вещей
Является ли репозиторий кода документом, который объясняет, как работают приложения, и должны ли разработчики найти знакомый и согласованный шаблон для проектов внутри организации (и за ее пределами)?
Используете ли вы контроль версий для управления кодом (надеюсь)?
Монорепозиторий облегчит вашей организации обслуживание
- Общие функции (например, аутентификация, аналитика, формы, утилиты)
- Общие службы (доступ к данным, HTTP, PubSub, состояние клиента)
- Брендинг и стиль пользовательских интерфейсов (UI)
- Последовательность для пользовательского опыта (UX)
- Линтинг/форматирование кода
- Внешние пакеты/зависимости и их версии
- Время сборки
- Документация
- Метрики репозитория и отчеты
- Конфигурация/координация развертывания
- Развертывания для разных сред
- Прототипы и шипы
- Ответственность за общий код
- Интеллектуальная собственность
- Доступ для внутреннего персонала, аутсорсинга и подрядчиков
- Кодовая база со многими участниками
Давайте посмотрим на доступные варианты хранения кода.
- монорепо
- Справочный репозиторий
- Полирепо
- Скопировать и вставить
монорепо
Создайте единый репозиторий для хранения всего кода для всех решений. Чтобы создать что-то индивидуальное, может потребоваться много работы, поэтому имеет смысл изучить инструменты и платформы, которые помогут управлять приложениями и библиотеками в одном репозитории.
Плюсы (воспринимаются)
- Легче поддерживать внешние пакеты/зависимости (сложность добавляется с большим количеством языков)
- Единое хранилище стилей кода, форматирования и линтинга для разных решений
- Все знают, над чем все работают, через PR в одном и том же репозитории.
- Пакеты также могут быть выпущены как пакеты NPM, если это необходимо.
- Тесты можно запускать на всех платформах при внесении изменений в общую службу/функцию/пакет.
Минусы (воспринимается)
- Еще один интерфейс командной строки
- Не решит проблему внешних зависимостей
- Слишком сложный для небольших проектов
- ИП для всех проектов в одном месте
- Ограничение доступа к приложениям/библиотекам для определенных команд/аутсорсеров
- Возможно более длительное время сборки
- Размер репозитория
- Организационная структура
- Другие причины, основанные на мнении :)
Справочное репо
Создайте эталонное репо, в которое будут добавлены все общие функции, например
- Общие стили
- Общие службы
- Создание приложений (базовая конфигурация сборки и развертывания)
- Линтинг/форматирование
Каждый новый проект разветвляет эталонное приложение и добавляет все остальные пакеты, необходимые для остальной части решения. Затем изменения в эталонном приложении могут быть объединены в ответвление.
Плюсы
- Общие пакеты могут синхронизироваться между платформами.
Минусы
- Множество кода, который может не потребоваться в форке
- Требует дисциплины для слияния в эталонном репо так часто, как оно меняется.
- Вилка может легко рассинхронизироваться с эталонным приложением.
- Не знаю, сломает ли изменение в общем пакете что-то в форке, пока он не будет объединен, что может означать, что он никогда не будет объединен.
Полирепо
Создавайте отдельные репозитории для каждого решения и используйте частные и/или общедоступные пакеты для обмена кодом между платформами.
Плюсы
- Публичные пакеты хороши для PR в инженерном сообществе с поддерживающими статьями и блогами.
- Четкие обязанности
Минусы
- Требуется много времени на поддержку, и разработчики всегда будут идти по пути наименьшего сопротивления.
- Требуется еще один уровень безопасности (AuthTokens) при доступе к частным пакетам.
Скопировать и вставить
Копируйте и вставляйте похожие функции между проектами
Плюсы
- Быстро и грязно — легко получить быстрые результаты
Минусы
- Что ж…
Результаты
Я начал писать вышеприведенное некоторое время назад для работы, а затем сделал его более общим для статьи. Я собирался опубликовать его на Medium, но не думал, что он говорит что-то новое или захватывающее, но чтобы сообщить об этом через 4 месяца, я надеюсь, что следующее поможет кому-то принять решение о том, следует ли им создавать монорепозиторий.
В итоге мы использовали NX для создания монорепозитория только для внешнего кода, а внутренние микросервисы находятся в отдельных отдельных репозиториях. На данный момент это работает хорошо для нас.
Наша организация разделена на три кросс-функциональные команды, а интерфейс Monorepo содержит веб-приложения React для просмотра и сбора данных и расширение для браузера Chrome (все они уже используются в производстве). На горизонте появится больше веб-приложений, поскольку мы перемещаем больше функций из монолита.
Мы быстро нашли двухнедельные встречи с фронтенд-инженерами для обсуждения изменений, и подход к новой работе оказался очень ценным. Мы строим только то, что знаем, и добавляем абстракции и общий код только тогда, когда это необходимо, а не потому, что нам кажется, что это нужно делать.
Мы создали общие библиотеки для HTTP-клиента, аутентификации, форм, шаблонов стилей и функций, общих для веб-приложений и подключаемого модуля браузера. Общие библиотеки, которые выглядят как пакеты NPM при импорте в TypeScript, позволили нам своевременно изменить третье приложение, поскольку мы повторно использовали много формы, макета и кода развертывания.
Веб-приложения используют конфигурацию сборки NX React, а расширение браузера расширяет конфигурацию сборки по умолчанию с помощью пользовательской конфигурации веб-пакета. Конвейеры CI/CD для каждого приложения отслеживают указанные каталоги и создают/тестируют/проверяют/развертывают только тогда, когда файлы в этих каталогах изменились.
Мы определили глобальные настройки для конфигурации prettier и eslint, чтобы поддерживать стандарты, которые при необходимости можно переопределить для каждого приложения/библиотеки (нам не приходилось этого делать).
Мы также недавно обновили пакеты NPM в репозитории с помощью команды NX Migrate, что заняло около 30 минут (включая незначительные обновления кода для изменений API).
Вывод
Является ли монорепо хорошей идеей? Как всегда, это зависит от… Мы чувствовали, что создание репозитория только для внешнего кода даст нам то, что нам нужно, благодаря доступным инструментам.
Мы выбрали NX, так как он удобен для предприятий и управляется Виктором Савкиным, который кажется умным парнем, и мы рады следовать мнениям, которые предлагает интерфейс командной строки.
Некоторые могут теперь обсудить использование термина Monorepo, поскольку репозиторий содержит только подраздел кода организации, но это только имя, и я бы сказал, организуйте свой код таким образом, который имеет смысл для вашей организации, и поймите ограничения с помощью того или иного метода. ты выбрал.
Организации и инженерам также необходимо было адаптироваться к новому способу работы, и в настоящее время они приносят нам пользу благодаря хорошему общению между командами.
Я уверен, что организация, в которой я работаю, хотела бы, чтобы у Google, Facebook и Microsoft были проблемы с большим количеством кода, но мы не такие большие. Мы понимаем, что некоторые приложения и код могут не принадлежать монорепозиторию, и мы должны напоминать себе об ответственности, соображениях и проблемах, которые мы пытаемся решить, имея много кода в одном репозитории.
