GA
человек 10
На 30 человеках система начинает клинить, на 50 встаёт и надо придумывать много-много костылей в процессы что бы оно не разваливалось.
Size: a a a
2019 September 25
GA
Да, dockerfile явно собирать, я же выше писал, про “… пришлось сохранить ту же структуру из multi-packaged repo…”
Ну ты ж понимаешь сколько раз в неделю этим отстреливают ноги при частых изменениях?)
GA
Прикол в том что с этой штукой не сработает "ну мы вот сейчас напишем, а как заработаем много денег и будем расширяться - вот тогда и распилим". Неа, когда будет больше денег бизнесу надо будет ещё больше денег, а у вас будет ещё больше людей которые будут перманентно уменьшать энтропию этой системы.
Б
На 30 человеках система начинает клинить, на 50 встаёт и надо придумывать много-много костылей в процессы что бы оно не разваливалось.
Чем поможет разбиение этого репозитория на 2 в таком случае?
Б
«Заклинивание» будет отсрочено?
AV
И как это поможет обновлению? В плане ты обновляешь пакет, там обновляются правила, после eslint --fix поменялось 10к строк и осталось 10к ошибок. А если и ошибки все руками поправил - по всему офису разносятся вопли людей которые правят merge конфликты.
Большие сквозные изменения это всегда грустно, и как вы с ними справляете, это наверное уже больше про организацию работы.
Обычно в mono-repo кто ломает, тот и чинит, меняя правила - идешь и правишь везде в этом же PR и да “по всему офису разносятся вопли”
но смотреть нужно по конкретной ситуации.
не хочу спорить 😂
Обычно в mono-repo кто ломает, тот и чинит, меняя правила - идешь и правишь везде в этом же PR и да “по всему офису разносятся вопли”
но смотреть нужно по конкретной ситуации.
не хочу спорить 😂
Б
Не спорю, просто действительно интересно узнать, что с этим не так
GA
Чем поможет разбиение этого репозитория на 2 в таком случае?
Не на два - на больше. У каждой команды/проекта/большой фичи своя репа (микросервис(ы)), на фронт это примерно так же масштабируется (но там сложнее, потому что деплоймент един для всех). Когда вы решаете обновить тулзу - вы просто её обновляете и решаете конфликты с самими собой. Когда эта штука активно не разрабатывается - она не мешает активно разрабатываться другим частям системы.
с
Надо как нибудь попасть на такой проект
А то пока я только вижу боль на немонорепе с малым числом разрабов
А то пока я только вижу боль на немонорепе с малым числом разрабов
AV
Не на два - на больше. У каждой команды/проекта/большой фичи своя репа (микросервис(ы)), на фронт это примерно так же масштабируется (но там сложнее, потому что деплоймент един для всех). Когда вы решаете обновить тулзу - вы просто её обновляете и решаете конфликты с самими собой. Когда эта штука активно не разрабатывается - она не мешает активно разрабатываться другим частям системы.
В этом подходе есть другая проблема.
Кто-то сидит на 1.0, кто-то на 1.2, кто-то на 2.0, а последняя версия уже 4.0.
И потом patch 4.1 фиксит важную security issue.
И если нету patch-backport для старых версий, то печаль
Кто-то сидит на 1.0, кто-то на 1.2, кто-то на 2.0, а последняя версия уже 4.0.
И потом patch 4.1 фиксит важную security issue.
И если нету patch-backport для старых версий, то печаль
с
В этом подходе есть другая проблема.
Кто-то сидит на 1.0, кто-то на 1.2, кто-то на 2.0, а последняя версия уже 4.0.
И потом patch 4.1 фиксит важную security issue.
И если нету patch-backport для старых версий, то печаль
Кто-то сидит на 1.0, кто-то на 1.2, кто-то на 2.0, а последняя версия уже 4.0.
И потом patch 4.1 фиксит важную security issue.
И если нету patch-backport для старых версий, то печаль
Ну если команды отдельные - каждая команда фиксит отдельно
GA
В этом подходе есть другая проблема.
Кто-то сидит на 1.0, кто-то на 1.2, кто-то на 2.0, а последняя версия уже 4.0.
И потом patch 4.1 фиксит важную security issue.
И если нету patch-backport для старых версий, то печаль
Кто-то сидит на 1.0, кто-то на 1.2, кто-то на 2.0, а последняя версия уже 4.0.
И потом patch 4.1 фиксит важную security issue.
И если нету patch-backport для старых версий, то печаль
Зависит от того как ваш конкретный бизнес относится к секурити, но не показательно, а на практике. Если это biotech, может финансы, тогда вам нужен renovatebot по крону который будет автоматически обновлять зависимости (либо кидать PR, опять же в зависимости от). Для глобального update есть mrm и чуть-чуть bash'а что бы стянуть все репы, но это на крайний случай.
с
Короче я понял
Мы собрали всю боль мультирепы
И не получили профита с этого
Мы собрали всю боль мультирепы
И не получили профита с этого
GA
Очень-очень редко видел серьёзные уязвимости в js модулях, там обычно какой-нибудь DoS через regexp и прочее-подобное.
GA
Ну и кстати монорепа этот вопрос не решает, потому что скорей всего просто не будет никто обновлять модуль с 1.0 до 2.0, ибо как мы помним процесс обновления болезненный.
AV
Короче я понял
Мы собрали всю боль мультирепы
И не получили профита с этого
Мы собрали всю боль мультирепы
И не получили профита с этого
можешь чуток поподробней?
с
можешь чуток поподробней?
Очень больно обновлять библиотеку которая используется в >5 репах
с
Пришлось скриптовать
AM
да, у нас есть тулза для такого, которая позволяет обновлять сотни наших либ
AV
Ну и кстати монорепа этот вопрос не решает, потому что скорей всего просто не будет никто обновлять модуль с 1.0 до 2.0, ибо как мы помним процесс обновления болезненный.
допустим мы пилим свою пакет/либу, она тоже лежит в монорепе, я сделал апдейт в либу (минор, мажор все равно), и я же пошел и всю кодовую базу на этот апдейт переписал.
С каждым изменением библиотеки меняется и кодовая база использующая либу
С каждым изменением библиотеки меняется и кодовая база использующая либу