Что затронет какой коммит отдельная история, это узнается одной командой из nrwl/nx клишки

Штука в том, что как раз деплой требует понимания что ты собираешь. А не то, что затронуто. Те понятие приложения поставлено ваше. Именно поэтому приходится собирать все + иметь кеш для того, что не изменилось.

С тестами и линтером проблем нет, а вот с артифактами как раз есть

Ладно, это моя боль с gitlab ci

Не особо понимаю о чем ты. Базовый формат монорепа, который даёт тот же nrwl/nx (да и даже angular/cli), этого кучка независимых приложений и, опционально, библиотек, которые напрямую используются в этих приложениях. У каждого приложения отдельный независимый деплой. Запуск деплоя любого приложения не требует никаких проверок на что-либо.

Если нужна совсем глубокая автоматизация с автоматическим определением что деплоить - nrwl/nx одной командой даёт список таких проектов, позволяет их сбилидить и имеет нек-й кэш для билдов. Но это уже для любителей, прекрасно жить можно и без этого

У меня nx со связанными проектами и distribution cache реализован и я скорее уже думаю/пишу про deployment flow и как понятно собирать проекты.
Да, можно все дать на откуп nx и там что-то будет само собираться, а что-то нет. Но нормально имплементировать в тот же gitlab ci это уже сложнее. Там следует делать предсказуемый процесс не только для девов, а и для qa. Чтобы было понятно что собралось и как это релизить. А тут уже приходится собирать все под кешем, по крайней мере пока на этом остановились.

Ну а теперь представим там 3-4 независимых проекта с точки зрения бизнеса и процессов. В общем тут уже все эти ci немного не справляются со своими задачами, так как они заточены на статическую сборку проектов, а не выборочную.

Всё ещё не понимаю проблему. У нас куа прекрасно сами всё деплоят. Смотрят список проектов затронутых пром, жмут соответствующие кнопки деплоя в дженкинсе у проектов, оно всё выкатывается

Ну ок, я написал выше, что у меня именно с gitlab вопросы. На обычных скриптах даже сделать такое вполне просто.

у меня всю жизнь деплоили разрабы, причем в бОльшей части кейсов там надо было еще деплоить в праивльное место, чтобы ничег оне затереть

прям завидую какие у вас классные qa

я, если шо, имел ввиду деплой на тестинг ) на прод разрабы сами катят т.к. должны быть в курсе что они там на проде сломали и быстро починить/откатить

так и я

Процессы разные, так что "должны" слишком сильное заявление. Прод вообще лучше не ломать, для этого и придумали stage

> Прод вообще лучше не ломать

в реальности это так не работает

В реальности есть разные процессы и ответственность с этим связанная. Опять же они могут отличаться от компании к компании.

это не зависит от процессов. Где-то меньше, где-то больше, но прод ломается везде. Как не бывает кода без багов (даже с тестами) и подобное

Конечно ломается. Вопрос в том, что кто за этим следит, какие процессы после этого вступают в работу и прочее.

полезла в webpack module federation, а тааааам