Поймите разницу между монорепо и полирепозиторием
Когда дело доходит до монорепозиториев и полирепозиториев, существует множество заблуждений. Эти неправильные представления могут вызвать путаницу, когда дело доходит до того, следует ли предпочесть одно другому.
В этой статье я познакомлю вас с обоими и помогу вам отличить их с подробным пониманием для лучшего принятия решений.
Коротко о монорепо
Монорепозиторий — это единый репозиторий для одного или нескольких проектов. Например, вы можете хранить код интерфейса и код сервера в двух разных папках в одном репозитории. Кроме того, в одном монорепозитории могут быть как связанные, так и независимые проекты.
Использование монорепозитория имеет несколько преимуществ, в том числе:
- Легко обмениваться кодом между проектами.
- Поддерживайте наборы тестов, сценарии автоматизации, конфигурации инфраструктуры в одном месте.
Крупные компании, такие как Google, Facebook и Microsoft, используют монорепозитории для поддержки своих проектов.
Но одно из распространенных заблуждений среди разработчиков заключается в том, что монорепозиторий увеличивает связанность кода приложения. Это неправда, поскольку в конечном счете монорепозиторий отвечает за систему управления версиями, а не за зависимости приложений.
Коротко о полирепо
Полирепозитории противоположны монорепозиториям. Когда команда внедряет полирепозитории, они пытаются идентифицировать различные проекты, компоненты и зависимости, прежде чем разбивать их на несколько репозиториев.
При работе с полирепозиторием есть несколько преимуществ:
- Помогает управлять контролем доступа отдельно для разных кодовых баз.
- Меньше конфликтов при «регистрации» кода.
- Меньше изменений для «вытягивания», если вы работаете с несколькими репозиториями.
Кроме того, при использовании некоторых инструментов DevOps становится легко создавать и публиковать, если они явно не поддерживают монорепозитории.
Давайте взглянем на факторы, которые вы должны учитывать, прежде чем сделать выбор в пользу одного из них.
Выбор между монорепозиторием или полирепо
1. Управление зависимостями
Монорепозиторий упрощает управление общими зависимостями. Например, когда вы впервые запускаете проект, вы, скорее всего, будете разрабатывать общий код внутри папки, и этот общий код регулярно обновляется. Основным преимуществом монорепозитория является то, что каждый компонент получает последнюю версию общего кода. Недостатком, однако, является то, что затронутые области высоки и требуют тщательного тестирования.
💡Здесь цепочка инструментов с открытым исходным кодом, такая как Bit, значительно упрощает разработчикам управление общими зависимостями. То, что раньше было утомительным, теперь можно контролировать из одного рабочего пространства.
С Bit процесс становится бесконечно более упорядоченным, так как в Bit Workspace вам не нужно указывать npm, pnpm или yarn, для каких компонентов необходимо установить зависимости, а также если это зависимость dev или prod. Bit динамически генерирует файлы package.json для каждого из них и может безболезненно с этим справиться. Узнайте, как это сделать, из этого руководства.
Напротив, полирепозитории требуют, чтобы вы либо публиковали общий код в виде библиотеки, либо использовали что-то вроде git-submodule или git-subtree. Следовательно, требуется более эффективное управление общим кодом, поскольку в разных проектах используются разные версии.
2. Сотрудничество
Монорепозитории обеспечивают лучшую видимость и совместную работу между командами, естественным образом поощряя повторное использование кода. Еще одним преимуществом является возможность стандартизировать код и инструменты для разных команд. Например, вы можете наложить политики ветвей, чтобы поддерживать чистоту в основной ветке, ограничить доступ к определенным ветвям, обеспечить соблюдение рекомендаций по именованию, включить рецензентов кода и применить лучшие практики, которые охватывают ваши команды. Таким образом, для команд, которые работают тесно и прозрачно, Monorepos помогает повысить производительность.
💡 Здесь снова может помочь Bit. С Bit вы можете легко совместно использовать и повторно использовать компоненты в разных проектах, гарантируя, что каждый компонент получит последнюю версию общего кода, что сэкономит вашей команде много времени и усилий.
Однако, если вы работаете с удаленными командами или имеете внешних сотрудников, предоставление точного контроля доступа может быть проблемой. Либо вы должны предоставить доступ ко всей кодовой базе, либо нет.
3. DevOps
Предположим, вам нужно выпустить все ваши компоненты сразу. В этом случае монорепозиторий может упростить DevOps, поскольку один репозиторий помогает собрать всю кодовую базу сразу.
Однако современные программные архитектуры, такие как микросервисы и микрофронтенды, снижают потребность в громких выпусках. Поэтому с помощью монорепозиториев вы можете управлять жизненным циклом компонентов независимо от структуры репозитория.
Одной из проблем с монорепозиториями является непрерывная интеграция для обнаружения изменений на определенных путях. К счастью, новые инструменты поддерживают триггеры сборки на основе пути, чтобы избежать этой проблемы.
4. Технический стек и размер
Обычно монорепозитории стремятся использовать совместимый стек технологий. В результате постепенное внедрение новых технологий может стать проблемой. Тем не менее, это не невозможно, так как мы привыкли хранить и интерфейс, и сервер в одном репозитории.
Кроме того, начать работу с такой большой кодовой базой в монорепозитории сложно. Между приложениями нет четкого разделения, и новым разработчикам предстоит многому научиться. Если вам не удастся отделить свой код, это также удорожает его модификацию для улучшения.
5. Рефакторинг
Монорепозитории обеспечивают атомарную фиксацию и значительно упрощают крупномасштабный рефакторинг. В одной фиксации разработчики могут обновить несколько пакетов или проектов.
В полирепозитории разработчики должны создавать запросы на вытягивание для каждого репозитория и выяснять, в каком порядке вносить изменения, тогда как в монорепозитории вам нужно только сделать атомарный запрос на слияние, который содержит все коммиты, связанные с функцией, над которой вы работаете. .
Кодовая база будет организована в виде единого дерева в монорепозитории, чтобы разработчики могли легко отслеживать зависимости.
Если ваша команда предпочитает делать атомарные коммиты, вам следует использовать монорепозитории.
Заключение
В этой статье я обсудил различия монорепозиториев и полирепозиториев, а также плюсы и минусы каждого из них. Однако нельзя прямо сказать, что кто-то из них хорош или плох. Это зависит от ваших требований, характера проекта, над которым вы работаете, и рабочей культуры организации, в которой вы работаете.
Наконец, помните, что правильный инструментарий необходим для эффективного монорепозитория. Отличными примерами таких инструментов являются Бит, Базел, Бак и Лерна.
И вот оно. Я надеюсь, что вы нашли это полезным. Спасибо за чтение!
Создавайте компонуемые веб-приложения
Не создавайте веб-монолиты. Используйте Bit для создания и компоновки несвязанных программных компонентов — в ваших любимых фреймворках, таких как React или Node. Создавайте масштабируемые интерфейсы и серверные части с мощным и приятным опытом разработки.
Перенесите свою команду в Bit Cloud, чтобы совместно размещать и совместно работать над компонентами, а также значительно ускорить, масштабировать и стандартизировать разработку в команде. Начните с компонуемых интерфейсов, таких как Design System или Micro Frontends, или исследуйте компонуемый сервер. Попробуйте →
Разделите приложения на компоненты, чтобы упростить разработку приложений, и наслаждайтесь наилучшими возможностями для рабочих процессов, которые вы хотите:
