Monorepo vs Polyrepo: архитектурный выбор, который определяет культуру команды

На первый взгляд это технический вопрос о том, как хранить код. На второй — это решение о том, как команды взаимодействуют, кто отвечает за качество и насколько быстро организация может двигаться. Google, Meta и Microsoft хранят большую часть кода в одном гигантском репозитории. Netflix, Amazon и большинство стартапов разбивают на сотни отдельных. Обе стратегии работают, но по-разному и при разных условиях.

Monorepo (монорепозиторий) — все проекты, сервисы и библиотеки организации хранятся в одном git-репозитории. Polyrepo — каждый сервис, библиотека или проект живёт в отдельном репозитории.

Google хранит в своём monorepo более 2 миллиардов строк кода в одном репозитории с 86 000 разработчиков.

Главное преимущество — видимость и согласованность. В monorepo любой разработчик может посмотреть, как устроен любой другой сервис. Общие библиотеки обновляются в одном месте — и все потребители сразу получают обновление (и сразу видят, если что-то сломалось). Рефакторинг через границы модулей — в одном PR, а не в десяти согласованных между командами.

Второе преимущество — атомарные изменения. Изменили API в библиотеке и обновили всех вызывающих в одном коммите. В polyrepo это требует координации нескольких репозиториев, версионирования и периода поддержки старой версии.

Третье — унифицированные инструменты. Один CI/CD, один линтер, одна система сборки для всего. Меньше конфигурационного дублирования.

Главный аргумент polyrepo — независимость команд. Каждая команда полностью владеет своим репозиторием: своим процессом деплоя, своими зависимостями, своим ритмом релизов. Нет ожидания, что чужой код сломает твой пайплайн.

Второе — масштабирование инструментов. Стандартный git плохо работает с репозиториями на миллиарды строк — Google создала собственную систему Piper поверх git, Meta использует EdenFS. Если у вас нет ресурсов Google — monorepo на стандартном git при определённом масштабе становится болью.

Третье — изоляция ответственности. В polyrepo понятно, кто за что отвечает. В monorepo границы размываются — и это хорошо для координации, но плохо для чёткого ownership.

Важное разграничение: monorepo — это про хранение кода, не про архитектуру приложения. Можно иметь monorepo из 50 микросервисов — и это распространённая практика.

Если команды сильно зависят друг от друга и нужна высокая скорость координации — monorepo. Если команды автономны и независимость важнее согласованности — polyrepo. Если растёте — помните, что переход из polyrepo в monorepo болезненен (нужно собирать историю из разных репозиториев), а из monorepo в polyrepo — ещё болезненнее (нужно разрезать и распутать зависимости).

Monorepo создаёт культуру общей ответственности: разработчик видит весь код и воспринимает качество в соседних сервисах как свою тему.

Polyrepo создаёт культуру сервисной изоляции: моя зона — мой репозиторий, что за стеной — не моё дело.

Ни одна из культур не лучше в абсолюте. Но они разные — и если архитектурный выбор не совпадает с желаемой культурой, возникает трение. Организации, которые хотят высокой согласованности и общего качества, часто обнаруживают, что polyrepo создаёт силосы, которые потом сложно разрушить. И наоборот.

Технический выбор — это и организационный выбор. Думайте об обоих уровнях одновременно.