RDCLR.DEV

Сколько репозиториев нужно проекту

На самом деле, все ответы из опроса выше были верными, просто тот или иной подход применим в зависимости от ваших задач. 🥰

🥑 Монорепа хороша для прототипов, PoC (Proof of Concept, когда нужно быстро собрать решение на коленке и убедиться, что технология работает, как ожидалось) и, например, конкурсно-тендерных историй, когда небольшое по объему решение нужно отдать на аудит. В этом случае нет никакого смысла плодить репозитоиии, достаточно обойтись одним.

🍒 Два репозитория (фронт и бэк) подойдут для небольших проектов с монолитным бэкендом и отдельным фронтом. В монолите нет ничего плохого, если проект не подразумевает развесистого функционала и грамотно написан.

🍇 Самым универсальным является подход, когда мы создаем по одному репозиторию на компонент. Примем, что компонент — это артефакт, то есть нечто, что можно собрать и использовать (устанавливать, деплоить) независимо от других частей системы. Это может быть Docker образ, общая библиотека, npm пакет, jar файл, скрипт для настройки инфраструктуры. Мы помним, что современные системы управления репозиториями умеют запускать CI/CD пайплайны (сборку, публикацию, деплой). И очень удобно иметь один репозиторий, триггерящий один сценарий сборки, который собирает один артефакт.

🥒 А самый популярный вариант в опросе — «зависит от архитектуры проекта и релизных процессов» — на самом деле покрывает предыдущие три и ничего конкретного не говорит

#rdclr_backend #rdclr_frontend #product

www.tgoop.com/rdclr_dev/66

315 viewsedited  Dec 27, 2021 at 16:20

Сколько репозиториев нужно проекту

На самом деле, все ответы из опроса выше были верными, просто тот или иной подход применим в зависимости от ваших задач. 🥰

🥑 Монорепа хороша для прототипов, PoC (Proof of Concept, когда нужно быстро собрать решение на коленке и убедиться, что технология работает, как ожидалось) и, например, конкурсно-тендерных историй, когда небольшое по объему решение нужно отдать на аудит. В этом случае нет никакого смысла плодить репозитоиии, достаточно обойтись одним.

🍒 Два репозитория (фронт и бэк) подойдут для небольших проектов с монолитным бэкендом и отдельным фронтом. В монолите нет ничего плохого, если проект не подразумевает развесистого функционала и грамотно написан.

🍇 Самым универсальным является подход, когда мы создаем по одному репозиторию на компонент. Примем, что компонент — это артефакт, то есть нечто, что можно собрать и использовать (устанавливать, деплоить) независимо от других частей системы. Это может быть Docker образ, общая библиотека, npm пакет, jar файл, скрипт для настройки инфраструктуры. Мы помним, что современные системы управления репозиториями умеют запускать CI/CD пайплайны (сборку, публикацию, деплой). И очень удобно иметь один репозиторий, триггерящий один сценарий сборки, который собирает один артефакт.

🥒 А самый популярный вариант в опросе — «зависит от архитектуры проекта и релизных процессов» — на самом деле покрывает предыдущие три и ничего конкретного не говорит

#rdclr_backend #rdclr_frontend #product

BY RDCLR.DEV