AM
Проблемы монорепозитория появляются на масштабах, до которых ещё надо дорасти и мало кому удаётся. Проблемы же с миллионом мелких реп вы получите прямо сразу.
Size: a a a
2020 August 17
П
К сожалению в отдельных случаях проблемы начинаются почти сразу(
VS
Andrei Moiseev
Проблемы монорепозитория появляются на масштабах, до которых ещё надо дорасти и мало кому удаётся. Проблемы же с миллионом мелких реп вы получите прямо сразу.
о каких проблемах идет речь в обоих случаях?
АЛ
в монорепе найти какой код за какой сервис отвечает, это особенно актуально, если нет трассибилите от требований до кода, зато нет проблем с тем, что структуры передаваемые из модуля в модуль не соотвествуют в источнике и приемнике
в куче реп искать сервисы проще (одна репа - один сервис), но проблемы интеграции встают в полный рост, надо какие-нибудь протобафы использовать
в куче реп искать сервисы проще (одна репа - один сервис), но проблемы интеграции встают в полный рост, надо какие-нибудь протобафы использовать
RT
в монорепе найти какой код за какой сервис отвечает, это особенно актуально, если нет трассибилите от требований до кода, зато нет проблем с тем, что структуры передаваемые из модуля в модуль не соотвествуют в источнике и приемнике
в куче реп искать сервисы проще (одна репа - один сервис), но проблемы интеграции встают в полный рост, надо какие-нибудь протобафы использовать
в куче реп искать сервисы проще (одна репа - один сервис), но проблемы интеграции встают в полный рост, надо какие-нибудь протобафы использовать
Монореп вряд ли проблему совместимости решит. Можно внести изменения в код нескольких компонент, но ведь их релиз будет не одновременным, между релизами совместимость интеграции все равно может развалиться. Все равно нужны дополнительные меры контроля целостности интеграций.
АЛ
Само собой
ci/cd как первая защита от разваливания
версионность api
использование принципа открытости-закрытости с поддержкой ненужных параметров и пометкой их устаревшими и с выпиливанием устаревших полей и, опять же, ci/cd вам подтердит, что поля больше нигде не используются
ci/cd как первая защита от разваливания
версионность api
использование принципа открытости-закрытости с поддержкой ненужных параметров и пометкой их устаревшими и с выпиливанием устаревших полей и, опять же, ci/cd вам подтердит, что поля больше нигде не используются
П
Само собой
ci/cd как первая защита от разваливания
версионность api
использование принципа открытости-закрытости с поддержкой ненужных параметров и пометкой их устаревшими и с выпиливанием устаревших полей и, опять же, ci/cd вам подтердит, что поля больше нигде не используются
ci/cd как первая защита от разваливания
версионность api
использование принципа открытости-закрытости с поддержкой ненужных параметров и пометкой их устаревшими и с выпиливанием устаревших полей и, опять же, ci/cd вам подтердит, что поля больше нигде не используются
чтобы ci/cd подтвердил, что поля нигде не используются кажется нужно пересобрать все проекты
АЛ
именно и такая возмоность есть в монорепе, проект и все что от него зависит пересобирается автоматом], ну и ночной (или субботний, если каждую ночь накладно) полный билд с прогоном тестов
PD
в монорепе найти какой код за какой сервис отвечает, это особенно актуально, если нет трассибилите от требований до кода, зато нет проблем с тем, что структуры передаваемые из модуля в модуль не соотвествуют в источнике и приемнике
в куче реп искать сервисы проще (одна репа - один сервис), но проблемы интеграции встают в полный рост, надо какие-нибудь протобафы использовать
в куче реп искать сервисы проще (одна репа - один сервис), но проблемы интеграции встают в полный рост, надо какие-нибудь протобафы использовать
А в чем проблема искать сервис в монорепе? При нормальной структуре этой монорепы?
АЛ
при нормальной структуре проблем меньше, но всегда есть шанс, что кто-то по незнанию впилит зависимость которой быть не должно, на ревью ёто пропустят, потом выпиливать окажется дорого и вот уже ваш сервис неожиданно зависит от вещей6 от которых по вашей структуре зависеть не должен...
PD
при нормальной структуре проблем меньше, но всегда есть шанс, что кто-то по незнанию впилит зависимость которой быть не должно, на ревью ёто пропустят, потом выпиливать окажется дорого и вот уже ваш сервис неожиданно зависит от вещей6 от которых по вашей структуре зависеть не должен...
Ну, так лишняя зависимость не зависит от монорепы или не монорепы.
Но вообще, увы, инструментов управления зависимостями по API я вообще не видел. Увы, ни OpenAPI, не protobuf ничего такого не предоставляют (и это причина, по которой я предпочитаю моностековые решения и хорошие IDE)
Но вообще, увы, инструментов управления зависимостями по API я вообще не видел. Увы, ни OpenAPI, не protobuf ничего такого не предоставляют (и это причина, по которой я предпочитаю моностековые решения и хорошие IDE)
PD
Но, конечно, для команд в 100+ человек моностек уже редко применим (
OS
Разницы между моно и не моно, по большому счёту, нет.
Одно легко превращается в другое и обратно.
Одно легко превращается в другое и обратно.
П
Обратно не всегда)))
OS
Это лет 5 назад было сложно. Сейчас уже полно инструментов - от выборочной компиляции до виртуальных файловых систем
LV
Мне странно вообще видеть участника коллективной деятельности без осознания своей роли в колективе в целом. Хотя такое вполне возможно.
Такое я вижу сильно чаще, чем хотелось. Тут уровень осознанности еще участника влияет. Кто более осознанный, тот больше таких проблем видит, как по мне.
П
Это лет 5 назад было сложно. Сейчас уже полно инструментов - от выборочной компиляции до виртуальных файловых систем
Если разрабы сделали много связей внутри, то разделить бывает не так просто.
OS
Что такое "связи внутри"?
П
зависимости между разными частями монорепы
LV
Как связан монорепозиторий и связность модулей между собой?