Монорепозитории – Что это такое и почему их так не любят

Kate · 28 Янв 2023

Вместо вступления

Самый популярный инструмент для работы с кодом это git. Он очень гибкий и удовлетворяет требованиям даже самых изысканных разработчиков. Основная рабочая директория в git называется репозиторием. Обычно для хранения одного приложения или сервиса используют один репозиторий. Таким образом небольшой бэкенд из 20 микросервисах располагается в 20 репозиториях.

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

Звучит неправдоподобно?

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

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

Один из путей решения этой проблемы — рефакторинг всей системы таким образом, чтобы максимально уменьшить зависимость сервисов друг от друга. После устранения слишком сильной связанности, нужно придумать, как заставить всех избавляться от старого API как можно скорее. К тому же было бы неплохо сначала найти путь уведомлять все зависимые сервисы об устаревании API. Здесь может помочь только автоматизация.

Наконец-то к теме

А вот другим способом решения является объединение всех сервисов в один большой монорепозиторий. Как только мы поместим все сервисы в один репозиторий, можно начинать проверять все зависимости во время компиляции, ведь теперь наш код физически находится в одном месте. После выполнения этих шагов, каждый раз, когда мы меняем API в сервисе и не меняем в зависимом, мы получим ошибку компиляции, что гораздо безопаснее, чем ошибка во время исполнения. Не забывайте, однако, что сервисы все равно доставляются не одновременно, и сохранение обратной совместимости в рамках одного релиза необходимо.

В этом и заключается основное преимущество монорепозиториев — все компоненты ПО физически находятся в одном месте. Это сильно развязывает нам руки для автоматизации и статического анализа кода и позволяет на самых ранних этапах, вплоть до машины разработчика, находить проблемы с зависимостями и решать их.

Почему же монорепозитории так непопулярны?

Однако недостатков у монорепозиториев существенно выше, хотя их вес в принятии итогового решения отличается для каждой ситуации.

Начнем с того, что для этого подходят далеко не все стратегии ветвления. Рассмотрим git flow. Мы все еще хотим доставлять сервисы по отдельности, а значит в нашем примере нам понадобится 20 релизных веток на одном репозитории, и это только начало. Выглядит это слишком запутанно и почти наверняка нам понадобится отдельная система менеджмента релизов. Многие компании, использующие монорепозитории так и поступают. Но самая подходящая стратегия — это trunk based, мы всегда гарантируем, что в нашей trunk/master ветке находится работающий код, который можно отправлять в бой. В качестве оптимизации развертывания, естественно, доставлять мы будем только те сервисы, которые действительно изменились с момента последнего обновления.

Со следующей проблемой столкнутся те, кто работает в современных IDE, таких, как IntelliJ Idea. Ведь вместо небольших проектов, расположенных отдельно, мы подаем ей на вход огромную папку с кучей проектов. Придется вручную настраивать только нужные вам проекты, но даже это не спасет вас от лагов при обновлении кода из удаленного репозитория. Для этой проблемы тоже придумали решение — плагины. Какие-то компании разрабатывают внутренние плагины для работы с монорепозиториями, кто-то использует общедоступные варианты.

До следующей проблемы дойдут далеко не все, ведь она появляется только при сильном росте репозитория. В какой-то момент git просто перестает справляться с количеством коммитов и изменений в рамках одного репозитория. Любая команда начинает занимать огромное количество времени и просто-напросто останавливает работу всех разработчиков. К сожалению, эту проблему решить не так-то и просто, так как встречаются с ней далеко не все. В моем опыте все огромные продукты, которые “переросли” git разрабатывают свои системы контроля версий, либо же модернизируют существующие.