Здравствуйте, CreatorCray, Вы писали:

P>>Я говорю совершенно другое — поскольку депенденсы могут отсутствовать, собранный релиз в докер имедже гораздо надежнее.
CC>Чем это отличается от хранения в докере всего, что надо чтоб одной кнопкой всё собрать?

Я тебе привел цельный список. В твоей схеме надо
1 хранить чуть не все возможные версии всех депенденсов
2 тратить чудовищное время на билд в силу естественных причин
3 приседать с переменными билда-деплоя каждый раз когда понадобится

P>>Ты издержки в терабайтах меряешь Нужно мерить и сравнивать суммарную стоимость владения.
CC>Издержки на хранение данных меряются как ни странно в объёмах данных, которые надо хранить. От этого всё дальше танцуется.

И всё равно надо считать суммарную стоимость владения. Например, каждый доп-сервис это плюс некоторый процент на ЗП опсов и админов.

Каждый билд — это время. Например, на предыдущем проекте включить старую версию на стг это дело секунд.

P>>Во первых, терабата мало.
CC>Возьми петабайт

Нужно считать не байты, а суммарную стоимость владения в деньгах.

P>> Во вторых, сюда нужно добавить зп опсов которые будут заниматься всеми подобными вопросами
CC>Они уже должны быть полюбас.

А капасити опсов по твоему неограничена?

P>>И нам нужно городить вокруг этого инфраструктуру, которая будет заботливо сохранять все используемые версии всех используемых депенденсов.
CC>Называется git

Еще один велосипед предлагаешь? Репозитории под артефакты уже давно изобрели.
Гит как хранилище артефактов работает плохо, его крайне трудно использовать, если у нас проекты разных сортов и депенденсы у всех разные, а размеры чудовищные.

P>>Элементарно — билды на фичи-баги-секюрити требуют зависимостей.
CC>Ну т.е. это не версионированный билд, это TOT.

Бывает по всяком, смотря какие задачи.

P>>Потому, что ты работаешь в узенькой нише.
CC>Эта узенькая ниша как раз занимается хранением всякого вашего говна.

Тем не менее, это узенькая ниша. Скажем, если собирать драйвер, десктоп приложение, или плагин к такому приложения, то тут билды падают раз в год, в основном когда заканчивается место на диске или протухают сертификаты.
Но если на том же агенте запускать стабильный билд стабильной версии веб-приложения и все будет иначе — и по времени, и по частоте сбоев.

P>> Веб-приложений разного масштаба в тысячи раз бОльше.
P>> Полная сборка проекта из исходников с деплойментом занимает часы, из которых бОльшую времени работает компилятор и идут тесты.
CC>Ты точно щас про веб?

Именно. Твое удивление говорит о том, что ты про веб-приложения только читал

P>>Щас ты наверное скажешь "а я веб-приложениями не занимаюсь" ?
CC>И слава богам, ибо помойка там страшная.

Не работал, но мнение имеешь

P>>Тесты можно и отключить, но тогда проблемы с интеграцией будешь ловить в отладке.
CC>А тебе точно надо гонять тесты для того, что уже было зафиксировано как срез годного билда?

Точно. Часть зависимостей в рантайме, соответсвенно я заранее и не знаю, годные они или нет. Небольшая мелочь может повалить всю цивилизацию, например — те самые переменные билда.

P>>То есть, в случае с хранением исходников:
P>>0. подкинуть нужные переменные окружения — где гарантия что они будут теми же, что и в прошлый раз? Есть ответ?

Забавно, что ответа от тебя не поступило. Гы!

P>>1. откопать тот самый пайплайн на дженкинсе или еще где, который умеет работать с билдами той самой версии и пускануть его
P>>2. скачать нужную версию исходников по тегу
P>>3. скачать все зависимости, коих обычно больше чем исходников, при чем намного
CC>Вы это что, всё врукопашную до сих пор делаете?

Где сказано, что это врукопашную? Все эти скачивания требуют времени и в силу того, что любая сеть принципиально ненадежка, именно на этом скачивании билд чаще всего и валится.

CC>Какой бардак!

Это обычное веб-приложение. Забавно, что ты не смог ничего выдать про переменные билда. Каким чудом собираешься обеспечить идентичность переменных?
А то потерял кое что, и твое приложение работать чуточку иначе. Что делать?