Size: a a a

Архитектура ИТ-решений

2020 August 17

AM

Andrei Moiseev in Архитектура ИТ-решений
Проблемы монорепозитория появляются на масштабах, до которых ещё надо дорасти и мало кому удаётся. Проблемы же с миллионом мелких реп вы получите прямо сразу.
источник

П

ПашМиш in Архитектура ИТ-решений
К сожалению в отдельных случаях проблемы начинаются почти сразу(
источник

VS

Vladislav 👻 Shishkov... in Архитектура ИТ-решений
Andrei Moiseev
Проблемы монорепозитория появляются на масштабах, до которых ещё надо дорасти и мало кому удаётся. Проблемы же с миллионом мелких реп вы получите прямо сразу.
о каких проблемах идет речь в обоих случаях?
источник

АЛ

Алексей Лосев... in Архитектура ИТ-решений
в монорепе найти какой код за какой сервис отвечает, это особенно актуально, если нет трассибилите от требований до кода, зато нет проблем с тем, что структуры передаваемые из модуля в модуль не соотвествуют в источнике и приемнике
в куче реп искать сервисы проще (одна репа - один сервис), но проблемы интеграции встают в полный рост, надо какие-нибудь протобафы использовать
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Алексей Лосев
в монорепе найти какой код за какой сервис отвечает, это особенно актуально, если нет трассибилите от требований до кода, зато нет проблем с тем, что структуры передаваемые из модуля в модуль не соотвествуют в источнике и приемнике
в куче реп искать сервисы проще (одна репа - один сервис), но проблемы интеграции встают в полный рост, надо какие-нибудь протобафы использовать
Монореп вряд ли проблему совместимости решит. Можно внести изменения в код нескольких компонент, но ведь их релиз будет не одновременным, между релизами совместимость интеграции все равно может развалиться. Все равно нужны дополнительные меры контроля целостности интеграций.
источник

АЛ

Алексей Лосев... in Архитектура ИТ-решений
Само собой
ci/cd как первая защита от разваливания
версионность api
использование принципа открытости-закрытости с поддержкой ненужных параметров и пометкой их устаревшими и с выпиливанием устаревших полей и, опять же, ci/cd вам подтердит, что поля больше нигде не используются
источник

П

ПашМиш in Архитектура ИТ-решений
Алексей Лосев
Само собой
ci/cd как первая защита от разваливания
версионность api
использование принципа открытости-закрытости с поддержкой ненужных параметров и пометкой их устаревшими и с выпиливанием устаревших полей и, опять же, ci/cd вам подтердит, что поля больше нигде не используются
чтобы ci/cd подтвердил, что поля нигде не используются кажется нужно пересобрать все проекты
источник

АЛ

Алексей Лосев... in Архитектура ИТ-решений
именно и такая возмоность есть в монорепе, проект и все что от него зависит пересобирается автоматом], ну и ночной (или субботний,  если каждую ночь накладно) полный билд с прогоном тестов
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Алексей Лосев
в монорепе найти какой код за какой сервис отвечает, это особенно актуально, если нет трассибилите от требований до кода, зато нет проблем с тем, что структуры передаваемые из модуля в модуль не соотвествуют в источнике и приемнике
в куче реп искать сервисы проще (одна репа - один сервис), но проблемы интеграции встают в полный рост, надо какие-нибудь протобафы использовать
А в чем проблема искать сервис в монорепе? При нормальной структуре этой монорепы?
источник

АЛ

Алексей Лосев... in Архитектура ИТ-решений
при нормальной структуре проблем меньше, но всегда есть шанс, что кто-то по незнанию впилит зависимость которой быть не должно, на ревью ёто пропустят, потом выпиливать окажется дорого и вот уже ваш сервис неожиданно зависит от вещей6 от которых по вашей структуре зависеть не должен...
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Алексей Лосев
при нормальной структуре проблем меньше, но всегда есть шанс, что кто-то по незнанию впилит зависимость которой быть не должно, на ревью ёто пропустят, потом выпиливать окажется дорого и вот уже ваш сервис неожиданно зависит от вещей6 от которых по вашей структуре зависеть не должен...
Ну, так лишняя зависимость не зависит от монорепы или не монорепы.
Но вообще, увы, инструментов управления зависимостями по API я вообще не видел. Увы, ни OpenAPI, не protobuf ничего такого не предоставляют (и это причина, по которой я предпочитаю моностековые решения и хорошие IDE)
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Но, конечно, для команд в 100+ человек моностек уже редко применим (
источник

OS

Oleg Soroka in Архитектура ИТ-решений
Разницы между моно и не моно, по большому счёту, нет.
Одно легко превращается в другое и обратно.
источник

П

ПашМиш in Архитектура ИТ-решений
Обратно не всегда)))
источник

OS

Oleg Soroka in Архитектура ИТ-решений
Это лет 5 назад было сложно. Сейчас уже полно инструментов - от выборочной компиляции до виртуальных файловых систем
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Alexander Luchkov
Мне странно вообще видеть участника коллективной деятельности без осознания своей роли в колективе в целом. Хотя такое вполне возможно.
Такое я вижу сильно чаще, чем хотелось. Тут уровень осознанности еще участника влияет. Кто более осознанный, тот больше таких проблем видит, как по мне.
источник

П

ПашМиш in Архитектура ИТ-решений
Oleg Soroka
Это лет 5 назад было сложно. Сейчас уже полно инструментов - от выборочной компиляции до виртуальных файловых систем
Если разрабы сделали много связей внутри, то разделить бывает не так просто.
источник

OS

Oleg Soroka in Архитектура ИТ-решений
Что такое "связи внутри"?
источник

П

ПашМиш in Архитектура ИТ-решений
зависимости между разными частями монорепы
источник

LV

Leonid Vygovskiy in Архитектура ИТ-решений
Как связан монорепозиторий и связность модулей между собой?
источник