Спор о том, как правильно организовать кодовую базу проекта — вечный.
1. Монорепозиторий (Monorepo) Весь код компании хранится в одном месте. Так делают Google, Meta, Uber, авторы Linux и Windows.
• Как устроено: Каждый сервис — это просто папка внутри гигантского репозитория. У каждой директории есть свои настройки сборки (BUILD) и файлы контроля прав (OWNERS).
• Плюсы: Общие зависимости для всей кодовой базы. Обновили версию библиотеки — она обновилась сразу везде. Действует единый высокий стандарт качества кода для всех команд.
• Минусы: Из-за колоссальных размеров кода обычный Git начинает тормозить. Приходится внедрять сложные инструменты автоматизации сборки вроде Bazel, Buck, Nix или Lerna.
2. Микрорепозитории (Microrepo) Каждому сервису — свой собственный изолированный дом. Это выбор Amazon, Netflix, LinkedIn и Oracle.
• Как устроено: Команда пилит свой микросервис в отдельном репозитории, полностью отвечая за сборку и доступы.
• Плюсы: Полная свобода. Команда сама решает, какие версии библиотек использовать и когда релизиться. Проект масштабируется быстрее на старте. Используются привычные инструменты вроде NPM, Maven, Gradle или CMake.
• Минусы: Со временем ты тупо устаешь управлять сотнями репозиториев. Качество кода у разных команд начинает сильно отличаться. Обновлять зависимости приходится вручную под график каждого сервиса.
Для маленького проекта или стартапа не нужно колхозить сложные схемы. Начните с микрорепозиториев на привычных инструментах. Но когда проект разрастется, а версии библиотек разъедутся в разные стороны, то пора смотреть в сторону монорепозитория
Какой подход к хранению кода вам кажется более удобным?
❤️ — Микрорепозитории
👍 — Монорепозиторий
🔹 Курс «Основы IT для непрограммистов»
🔹 Получить консультацию менеджера
🔹 Сайт Академии 🔹 Сайт Proglib
🏃♀️ Азбука айтишника
#ликбез