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

P>>В твоей схеме надо
P>>1 хранить чуть не все возможные версии всех депенденсов
CC>Нет. Ровно только то, что было использовано в билде.

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

P>>2 тратить чудовищное время на билд в силу естественных причин
CC>Зависит от use case, в большинстве случаев когда надо за каким то хреном полезть в старьё — один фиг надо его исходники и весь environment, да и патч надо на том же сабсете делать, так что сборка одиг фиг нужна.

Это только один из use case. А когда нужен bisect, необходимость билдовать убивает весь бенефит.

P>>3 приседать с переменными билда-деплоя каждый раз когда понадобится
CC>Никакой рукопашки, всё это уже должно быть в самом проекте.

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

Т.е. сеть принципиально а) нестабильна б) постоянно в изменениях. Это из букваря по веб-приложениям.

P>>А капасити опсов по твоему неограничена?
CC>Чем вынуть тэг из архива и собрать его принципиально отличается от собрать один из текущих тэгов?

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

P>> Еще один велосипед предлагаешь? Репозитории под артефакты уже давно изобрели.
CC>Это потому что ты мыслишь только в готовых бинарях.

Мы здесь про депенденсы. Ты что, собираешься и депенденсы пересобирать?

P>>Но если на том же агенте запускать стабильный билд стабильной версии веб-приложения и все будет иначе — и по времени, и по частоте сбоев.
CC>Т.е. ты щас сам признался что даже "стабильный билд стабильной версии веб-приложения" глючит всеми цветами радуги

Стабильный билд — пусканули пять раз подряд, всё зелено. Но это не гарантирует, что и через погода будет так же. Например, за эти полгода админы точно применять десяток или сотню фиксов секюрити, закроют то или это именно по причинам секюрити.
Например — запретили basic http, а вместо этого oidc client_credentials grant.
Твой билдец накрылся, потому что грейс период был три месяца, а прошло полгода.


CC>>>Ты точно щас про веб?
P>>Именно. Твое удивление говорит о том, что ты про веб-приложения только читал
CC>Удивление?

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

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

P>>Точно. Часть зависимостей в рантайме, соответсвенно я заранее и не знаю, годные они или нет. Небольшая мелочь может повалить всю цивилизацию, например — те самые переменные билда.
CC>В этом то и проблема что у тебя никогда нет стабильного билда. И не будет.
CC>Говно и палки, печаль!

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

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

Автоматичность не страхует от сбоев. Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)

P>>Забавно, что ты не смог ничего выдать про переменные билда.
CC> Забавно что для тебя "переменные билда" это нечто, что надо "подкидывать" без "гарантий что они будут теми же, что и в прошлый раз".
CC>Это лютый бардак, говно и палки.

Цитирую себя

Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)

Следствие из этого — все конфиги рано или поздно протухают.

P>> Каким чудом собираешься обеспечить идентичность переменных?
CC>Суть проблемы вообще не понятна. Что значит "собираешься обеспечить"? У тебя что, сборка врукопашную делается, набирая команды в терминале по памяти?

Цитирую себя:

Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)

Следствие из этого — все конфиги рано или поздно протухают.
На новых конфигах приложение работает трохи иначе. Упс!

P>>А то потерял кое что, и твое приложение работать чуточку иначе. Что делать?
CC>Делать чтобы ВЕСЬ билд собирался одной кнопкой. Чтоб не надо было думать какие там переменные надо ручонками выставить.

Спасибо, капитан! Вот пусканул ты старый билд, а с тех пор админы запретили basic-http, по которому стучится твой билд. Твои действия?

CC>Впрочем с подходом "каждый раз тянется зоопарк из интернетов" такую элементарную вещь как повторяемый билд сделать нельзя, да. Ибо никто не знает какое говно скачается в следующий раз.

Цитирую себя:

Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)

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

P>>В твоей схеме надо
P>>1 хранить чуть не все возможные версии всех депенденсов
CC>Нет. Ровно только то, что было использовано в билде.

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

P>>2 тратить чудовищное время на билд в силу естественных причин
CC>Зависит от use case, в большинстве случаев когда надо за каким то хреном полезть в старьё — один фиг надо его исходники и весь environment, да и патч надо на том же сабсете делать, так что сборка одиг фиг нужна.

Это только один из use case. А когда нужен bisect, необходимость билдовать убивает весь бенефит.

P>>3 приседать с переменными билда-деплоя каждый раз когда понадобится
CC>Никакой рукопашки, всё это уже должно быть в самом проекте.

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

Т.е. сеть принципиально а) нестабильна б) постоянно в изменениях. Это из букваря по веб-приложениям.

P>>А капасити опсов по твоему неограничена?
CC>Чем вынуть тэг из архива и собрать его принципиально отличается от собрать один из текущих тэгов?

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

P>> Еще один велосипед предлагаешь? Репозитории под артефакты уже давно изобрели.
CC>Это потому что ты мыслишь только в готовых бинарях.

Мы здесь про депенденсы. Ты что, собираешься и депенденсы пересобирать?

P>>Но если на том же агенте запускать стабильный билд стабильной версии веб-приложения и все будет иначе — и по времени, и по частоте сбоев.
CC>Т.е. ты щас сам признался что даже "стабильный билд стабильной версии веб-приложения" глючит всеми цветами радуги

Стабильный билд — пусканули пять раз подряд, всё зелено. Но это не гарантирует, что и через погода будет так же. Например, за эти полгода админы точно применять десяток или сотню фиксов секюрити, закроют то или это именно по причинам секюрити.
Например — запретили basic http, а вместо этого oidc client_credentials grant.
Твой билдец накрылся, потому что грейс период был три месяца, а прошло полгода.


CC>>>Ты точно щас про веб?
P>>Именно. Твое удивление говорит о том, что ты про веб-приложения только читал
CC>Удивление?

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

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

P>>Точно. Часть зависимостей в рантайме, соответсвенно я заранее и не знаю, годные они или нет. Небольшая мелочь может повалить всю цивилизацию, например — те самые переменные билда.
CC>В этом то и проблема что у тебя никогда нет стабильного билда. И не будет.
CC>Говно и палки, печаль!

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

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

Автоматичность не страхует от сбоев. Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)

P>>Забавно, что ты не смог ничего выдать про переменные билда.
CC> Забавно что для тебя "переменные билда" это нечто, что надо "подкидывать" без "гарантий что они будут теми же, что и в прошлый раз".
CC>Это лютый бардак, говно и палки.

Цитирую себя

Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)

Следствие из этого — все конфиги рано или поздно протухают.

P>> Каким чудом собираешься обеспечить идентичность переменных?
CC>Суть проблемы вообще не понятна. Что значит "собираешься обеспечить"? У тебя что, сборка врукопашную делается, набирая команды в терминале по памяти?

Цитирую себя:

Сеть а) принципиально ненадежна б) постоянно в изменениях (секюрити, миграции, апгрейды железа, итд итд)

Следствие из этого — все конфиги рано или поздно протухают.
На новых конфигах приложение работает трохи иначе. Упс!

P>>А то потерял кое что, и твое приложение работать чуточку иначе. Что делать?
CC>Делать чтобы ВЕСЬ билд собирался одной кнопкой. Чтоб не надо было думать какие там переменные надо ручонками выставить.

Спасибо, капитан! Вот пусканул ты старый билд, а с тех пор админы запретили basic-http, по которому стучится твой билд. Твои действия?

CC>Впрочем с подходом "каждый раз тянется зоопарк из интернетов" такую элементарную вещь как повторяемый билд сделать нельзя, да. Ибо никто не знает какое говно скачается в следующий раз.

Дело даже не в интернетах, сеть в каждой конторе меняется постоянно, инфраструктура — меняется, имена меняются, секюрити фиксы идут непрерывным потоком.
Заюзал ты функцию "скачаю я с локального сервера вон то", а в следующий раз этот локальный сервис скажет "этот запрос со вчерашного дня не секюрный, делай запрос секюрно"