Y
Вот по ссылочке TLDR: http://danluu.com/monorepo/
Ответ на вопрос why: плохо кидать ссылку на эдвантеджес без дизэдватеждес ;)
Size: a a a
2021 March 09
DT
Дисэдвантаджес я выше написал: нужно много инвстировать в инфоаструктуру
MS
Дисэдвантаджес я выше написал: нужно много инвстировать в инфоаструктуру
с монорепой?
DT
Вплоть до написания свой VCS и системы сборки. Мало кто может себе это позволить
MS
у нас наоборот сейчас, пока монорепо все проще сильно
DT
с монорепой?
Yep
DT
у нас наоборот сейчас, пока монорепо все проще сильно
Это она маленькая еще. Потом начнете упираться в скорость сборки и в гит
DT
Это она маленькая еще. Потом начнете упираться в скорость сборки и в гит
Сборки и тестов
MS
Это она маленькая еще. Потом начнете упираться в скорость сборки и в гит
ну да, у нас по факту фронт, бек, микросервис небольшой и е2е
VI
Кстати да, у нас тоже есть монорепа и для неё нужно уметь делать пайплайны. Мне казалось, что у Гитлаба как раз есть возможность пайплайны по директориям проектов напихать и нормально должно работать без переусложнений. Всё не так?
сначала да, получается красота, там есть change filters. но потом это добро начинает неконтролируемо расти + у гитлаба есть свои очень большие приколы с асинк пайплайнами
VI
например, хочешь ты в одной репе держать сервис + клиентскую либу к нему, пилишь пайплайн - 2 теста, 2 билда, один паблиш в артифактори, один деплой на стейдж и один на прод.
делаешь асинк зависимости - тест -> билд -> деплой зависят по своему флоу, клиентская либа по своему. пишешь change filters на разные папки
делаешь асинк зависимости - тест -> билд -> деплой зависят по своему флоу, клиентская либа по своему. пишешь change filters на разные папки
VI
и ты думаешь, что гитлаб нормальный инструмент, достаточно будет написать что билд зависит от тестов, а деплой от билда, но нет. его делали программиты для программистов, это правда)
DT
и ты думаешь, что гитлаб нормальный инструмент, достаточно будет написать что билд зависит от тестов, а деплой от билда, но нет. его делали программиты для программистов, это правда)
🙃
VI
надо перечислять все зависимости на каждом шаге. в деплое явно написать, что оно зависит и от билда, и от теста.
иначе, если тест упадёт, а ты не прописал от него зависимость деплоя, а только билду его прописал.. то билд просто скипнется. а скип статус в гитлабе по дефолту = success )
иначе, если тест упадёт, а ты не прописал от него зависимость деплоя, а только билду его прописал.. то билд просто скипнется. а скип статус в гитлабе по дефолту = success )
Y
и ты думаешь, что гитлаб нормальный инструмент, достаточно будет написать что билд зависит от тестов, а деплой от билда, но нет. его делали программиты для программистов, это правда)
Я вот так и говорю. Это месть айтишникам за все говеные продукты которые они дали пользователям
VI
и у тебя начинается деплой того, чего не прошло тесты и даже не собралось)
VI
а теперь наш кейс: у нас есть несколько коммон либ, без которых нельзя заливаться, если они не собрались и не прошли тесты. и блок с зависимостями деплоя одного сервиса может выглядеть так
VI
а теперь представь, какие должны быть change filters для каждой из джоб? правильно, одинаковые
AR
Недавно у меня поломались все пайплайны в гитхабе, в которых была либа pg:
Просто на ровном месте. Случилось это ночью, админ спал и пришлось применить старую админскую магию "надо немножко подождать". Утром эти же пайплайны прошли без проблем.
Что было - хз ) Но, как можно заметить, что в неконтролируемом окружении ваш деплой может превратиться в тыкву.
gyp ERR! System Linux 5.4.0-1039-azure
gyp ERR! command "/usr/local/bin/node" "/usr/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /app/node_modules/libpq
gyp ERR! node -v v12.20.1
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok
Просто на ровном месте. Случилось это ночью, админ спал и пришлось применить старую админскую магию "надо немножко подождать". Утром эти же пайплайны прошли без проблем.
Что было - хз ) Но, как можно заметить, что в неконтролируемом окружении ваш деплой может превратиться в тыкву.