Политика — это концентрированное выражение экономики

или наоброт

Диалектика же ¯\_(ツ)_/¯

а можно как то импортировать jar кодстаил в идею? А то мне скинули джарник, а идея принимает только xml

всем привет. По неопытности возник вопрос, поделитесь опытом, пожалуйста? есть у меня дев стенд для разработчиков. Там все на docker-compose. Решил я переделать все это и привести окружения к одному виду. Хочу, чтобы все крутилось в кубере, потому что подакшен и стейдж в кубере. У разработчика возник вопрос, что делать в том случае, если он хочет на горячую что-то в контейнере поменять, на деве разумеется, потому что оч надо, без пайплайна. Я немного расстерян, потому что не понимаю, нормален ли такой подход

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

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

Ну тут х** поспоришь, аргумент железный) только данный аргумент и для прода работает)

вроде бы, некоторые практикуют такое. Даже тулы есть, типа - https://github.com/GoogleContainerTools/skaffold

а вообще, какая разнциа что будет на Dev, главное, чтобы до важных окружений код не проходил мимо пайплайнов, имхо, конечно

Наинается разброд и шатание в плане CD. В одном месте одно, в другом другое. Просто хочу понять, стоит ли настаивать на переходе, либо подстроиться под нужды. Оправдан ли такой подход

ну в моем понимании, development environment должен максимально близко быть похожим на production, иначе, может быть какое-то непредвиденное поведение на production, которые можно было отловить на этапе тестирования

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

подкинь ему контраргумент, что его изменения пойдут мимо автотестов => он по факту минует соблюдение контракта какого-то метода, но тут опять же, все зависит от хар-ра изменений

контейнеры подразумевают immutable и если меняются, то целиком - если долго контейнер собирается, то лучше добавление jar в конец dockerfile добавить
если прям совсем нельзя файл поменять - то можно сделать подключение jar как volume и рестартовать контейнер когда надо

Тут можно возразить, что тестировать нужно на test enviroment
А на dev enviroment нужна возможность _быстро_ проверять _много_ гипотез. И если пайплайн долгий - то он не годится для dev enviroment, нужно его переделывать

соглашусь, просто по описанию автора не совсем было понятно есть ли у них вообще test, но да, в таком случае pipeline надо менять

Что посмотреть на карантине? Подборка материалов от Технострима (часть 1)
https://habr.com/ru/post/498500/