И зачем докер-контейнер обязательно?

А какой профит в джаве от докера? Ты же уже запаковал все в fatjar, тебе для работы нужна только jvm же

to be a hip

профит лично для меня и команды - быстрое развертывание и деплоймент

такое чувство что докер придумали javascript-еры )

которые не смогли осилить настройку apache или nginx )

профит лично для меня и команды - быстрое развертывание и деплоймент

docker run blabla vs java -jar fatjar

docker run blabla vs java -jar fatjar

только в первом случае отгрызается сразу же до утра памяти. И не отпускается.

Вот даже не знаю, с языками где постоянно всё меняется есть профит, но джавка же стабильна как камень

смотри гуга, ты пример привел с одной стороны

Если что, я не особо прошареный в это теме.

вопрос, откуда ты берешь джарку?

как миниму тебе надо её собрать

подтянуть зависимости

скачать исходники

а мне достаточно будет сделать docker pull

ага, т.е. ты в докере собираешь свой джарник?

aways a better way exists

There is always a better way

в докере, докер собирает мой джарник

а рулит всем сиай

вот прямо делаешь COMAND: "gradle build"?

да

ну как-то читал за кейсы когда у чуваков был томкат и к нему подкидывался war и вся фигня это все крутилось внутри докера, они поменяли это на условный spring boot с embed сервером. и при этом админы об этом даже не знали

только mvn package + options

ну как-то читал за кейсы когда у чуваков был томкат и к нему подкидывался war и вся фигня это все крутилось внутри докера, они поменяли это на условный spring boot с embed сервером. и при этом админы об этом даже не знали

плюсую

только mvn package + options

т.е. у тебя в образе ещё и мавен есть?

о_О

т.е. у тебя в образе ещё и мавен есть?

да, мэйвен образ

обычная практика

и сорс код?)

сорс код на сиай лежит

гитлаб сиай отлично с докером дружат

А что мешает сделать fatjar на ci?

и сделать образ докера только с жабкой?

вот пример выше классный был, не всегда деплой идет как фэт джар

Насколько я понимаю докер это о деплое, а не о сборке

мы в свое время хотели сделать

что будет если ты не сможешь сбилдить проект уже внутри докера?

Насколько я понимаю докер это о деплое, а не о сборке

и сборка (образа) и деплой (артифактори)

чтоб каждую ветку отдельно в докере деплоить

но поняли что это боль с тестовой бд

что будет если ты не сможешь сбилдить проект уже внутри докера?

видимо упадут тесты

чтоб каждую ветку отдельно в докере деплоить

ой, зачем так сложно?

сделайте триггер на мастер/стэйбл и все

ой, зачем так сложно?

ну типа чтоб проверять что в этой ветке все ок

Ладно, я всё равно не шарю в этом всё devops'e и даже не особо интересно

чтоб чуваки из qa все тестировали

чтоб чуваки из qa все тестировали

ааа, т.е. хотите несколько веток на отдельный сервак натравить?

угу

и можно было ходить на #task_num.example.com

ну можно сделать такое, правда по феншую образов докера станет многовато

по образу на ветку

а они дохнут по факту мерджа

т.е. 1 интеграционная-куа-ветка и в нее мержите остальные?

тогда и 1 образом можно обойтись будет

т.е. 1 тестирование - в #task_num, потом qa после мержа

потом master и в деплой

на прод

нормально

но мы уперлись что в qa используется бд с прода

а там овердохера данных

вот еще, отвечая на вопрос гуги, java -jar fat.jar - это наивный случай, там же еще куча опций жвм идет в нагрузку, образ инкапсулирует в себе весь конфиг, удобно его сразу таскасть с собой.

но мы уперлись что в qa используется бд с прода

отдельная схема?

угу, схемы разные

а данных много(

и основной упор на них

нет, решить можно было

ERROR: S client not available

но мы решили тупо сократить прогеров ))))

и сейчас у нас просто ветка dev, ветка master :D

а под стори/таски не отводите?

и сейчас у нас просто ветка dev, ветка master :D

у вас любой девелопер может сам в dev пушить?

и сейчас у нас просто ветка dev, ветка master :D

как часто дев в мастер идет?

у вас любой девелопер может сам в dev пушить?

а почему нет, гуга? Вот в мастер по идее лиды мержить должны.

а почему нет, гуга? Вот в мастер по идее лиды мержить должны.

ну как минимум код ревью, а как максимум нерабочий код в деве.

у вас любой девелопер может сам в dev пушить?

c учетом что нас всего двое? да

как часто дев в мастер идет?

сейчас уже каждый раз как чето сделали

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

уровня git push origin HEAD:dev git push origin HEAD:master

но у нас все совсем плохо))

у нас и код ревью раньше был))

c учетом что нас всего двое? да

Я вот думал что вас человек 5. А так да, нету смысла городить много уровней когда вас пара человек.

нас было 12

остались только 2 ведущих

еще один вопрос, есть: - com.company.users.controllers - com.company.mainapp вызов с основного mainapp есть, а вот как подключить другие пакеты (уже врубился что они так называются тут, а не модули :))? Такое чувство что надо что-то добавить в MainappApplication, но доказать не могу )

@JBaruch в самолете инет есть?)

только mvn package + options

Это, конечно, адовый пиздец. Просто адовый. Но раз работает, и вы довольны, то кто я такой, чтобы критиковать прекрасное. Вон, react в Экселе народ пишет, и ничего.

rx

react это "немножко" другое

Это, конечно, адовый пиздец. Просто адовый. Но раз работает, и вы довольны, то кто я такой, чтобы критиковать прекрасное. Вон, react в Экселе народ пишет, и ничего.

а в чем такая адовость?

а в чем такая адовость?

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

а, в этом плане

rx

Сорян, rx конечно

мне чатик прям нравиться стал :)

Огонь же

просто адски интересно теперь послушать, как кто деплоймент делает и что происходит на старте приложения до тех пор пока приложение доступным не станет

я думаю это будет набор просто великолепных историй

У нас гифка крутится

Огонь же

вот да