Как стать автором
Обновить

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вместо заключения

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

Теги:
Хабы:
Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.