Нам надоело! Переезжаем на монорепозиторий
Не потому, что монорепозиторий моднее. Просто в какой-то момент несколько репозиториев начинают создавать больше проблем, чем решать.
Рассмотрим типичный случай: библиотека живёт в отдельном репозитории, собирается в артефакт, приложение подключает конкретную версию. Меняем библиотеку — публикуем новый артефакт, обновляем версию, снова собираем. И так по кругу.
Пока компонентов немного, это отлично работает. Но когда их становится много, появляется отдельный слой инфраструктуры: публикация артефактов, синхронизация версий, разные состояния dev и master, дополнительные этапы CI и ошибки на стыках между репозиториями.
В какой-то момент возникает простой вопрос: «Зачем вообще держать эти компоненты в разных репозиториях, если они развиваются как части одного продукта?».
Монорепозиторий позволяет оставить модульность, но убрать лишнюю границу между репозиториями. Каждый компонент остаётся отдельным Gradle-модулем со своим API и внутренней реализацией, но всё находится в одном графе зависимостей и собирается из одного состояния исходников. При этом монорепозиторий не означает «один огромный модуль». Наоборот, смысл как раз в том, чтобы сохранить хорошие границы внутри одного репозитория.
И здесь есть ещё один интересный момент. Отдельный репозиторий часто появляется по вполне реальной причине: другой владелец, другой уровень доступа, несколько независимых потребителей или отдельный цикл релизов. Но со временем причина может исчезнуть, а граница остаться. И тогда то, что когда-то было архитектурным решением, превращается просто в историческое наследие.
Поэтому перед созданием очередного репозитория полезно спросить себя: «Какую конкретную проблему он решает, и действительно ли эта проблема всё ещё существует?».
Если нет, возможно, пора оставить модули, но убрать репозитории.
