Java-enterprise

Реализовать параллельный запуск на ферму серверов в зависимости от конфигураций теста из одной дженкинс-задачи? А зачем мне тогде дженкинс, если мне его логику писать придётся на уровне тестового фреймворка?

Вот, а дженкис если ты не знала - это запускалка примитивных тестов - шаг влево начинается ад. И с расширяемостью у него не лады (кто видел его сорцы тот знает). И так со всеми инструментами, потому покуда ты увеличиваешь количество и сложность используемых кривых инструментов - тебе будет только хуже.

И все это для того чтобы не использовать готовый механизм шаблонов?

Который порождает кучу проблем, ага.

И это ты даже не начал ещё думать про code-review для конфигураций этих самых jenkins-задач.

О ужас, а кофейные кружки девелоперов тоже надо ревьювить? Будь проще.

Аргументы у тебя в стиле: с каждым из примеров можно бороться в отдельности, либо отказывая себе в функциональности, либо заменяя её своими домашними разработками, «по-простому».

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

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

Там и на LTS проблемы были, помнится. libvirt как-то нехорошо обновлялся.

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

Если вы кроме как писать костыли больше ничего не можете, то да вариантов нет 8)

К слову, это пройдет, щас вот ты узнала что жиру писали быдлокодеры, когда дойдет дело до ковыряния в энтерпрайз-левел тузле и после декомпиляции ты увидишь что там, то вспомнишь меня и пойдете писать свои «недокументированные костыли», потому что не боги горшки обжигают, и все, все эти вот инструменты написаны такимиже программистами, а то и хуже.

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

Знаешь это все круче чем виндовые консоли крутящие транзакции - то вся я насмотрелся, а вот такой юношеский энтерпрайз, когда на каждую задачу решение - новый интерпрайз-иснтрумент, ой их много, ничего, есть интерпрайз управлялка! Ой она не умеет вот этим рулить. Ставим еще управлялку, и над ними еще и так бесконечно. Блин я уже хочу видеть схему вашего процесса разработки.

где ты про enterprise-level тулзы-то вычитал, я про зеркало pypi говорила, и репы deb-пакетов

Блин я уже хочу видеть схему вашего процесса разработки.

Свою не покажу, рисовать долго, но вот сюда можешь глянуть:

http://docs.openstack.org/infra/system-config/

Хотя лучше сюда, если про процесс речь http://docs.openstack.org/infra/manual/developers.html

enterprise-level тулзы-то вычитал, я про зеркало pypi говорила, и репы deb-пакетов

Понимаешь в чем дело, эти штуки, какбы не нужны в разработке на java, ну вообще.

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

Женскинс у нс ставиться один раз, и для него держать зеркало питона в здравом уме никто не будет - оно не нужно он же один раз ставится.

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

понимаешь в чем дело, эти штуки, какбы не нужны в разработке на java, ну вообще.

то есть всё-таки в воздухе и солнечным светом

dev и stage окружения у вас есть? или тоже IDE достаточно?

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

и вот когда это делается раз в сотню лет - это делает senior разработчик руками на своем ноутбуке? А когда он уволится, знание уйдет вместе с ним.

А про security-обновления речи не идет от слова совсем.

dev и stage окружения у вас есть? или тоже IDE достаточно?

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

Для управления этим дермом мы написали утилиту, которая уже в опенсурсе и (когда фронтэндщики разродятся) даже начнем пиарить.

и вот когда это делается раз в сотню лет - это делает senior разработчик руками на своем ноутбуке?

на прошлой работе я один раз настроил, написал инструкицю и отдал админу, он сделал тестовую установку и все.

А про security-обновления речи не идет от слова совсем.

Это для них тебе полинтернета надо отзеркалить?

Для управления этим дермом мы написали утилиту, которая уже в опенсурсе

О, а можно ссылку ?

там только бэкенд пока, фронтэнд все никак не выложат в паблик 8(

ты в мирантисе, что ли, работаешь?

Уже нет, но была там, да.

Пустой спор на самом деле. Я говорю: нет нормальных инструментов для организации инфраструктуры, а энтерпрайзными пользоваться невозможно; и ты по сути говоришь то же самое.

Только ты делаешь вывод, что нет и не надо. А я - что нет, а хорошо бы.

А в итоге все пилим свои костыли :)

Только ты делаешь вывод, что нет и не надо. А я - что нет, а хорошо бы.

Ну вообщето я еще рассказываю почему их нет, и не будет.

Не будет в виде «один комбайн на всё» - да. А вот насчет интерфейса, проксирующего разные форматы реп например, или того же парсера yaml в Jenkins-xml, которым является jenkins-job-builder - тут стоит посмотреть.

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

А вот насчет интерфейса, проксирующего разные форматы реп например,

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

Вполне очевидно что для докера пришлось ставить официальную реализацию - т.к. никто за этими хиспторами которые с каждым релизом что-то ломает не успеет. И вариантов тут нет и не будет, потому, что авторы докера - хипсторы, не способные один раз продумать перед тем как писать, а авторы нексуса - лентяи и тоже не умеют проектировать ПО.

Почему модуль женкинса требует питон? Потому что никто (в т.ч. ты) не написал модуль на java. Тебя устраивает существующий костыль, а остальным он не нужен.

Потому никогда не будет этого самого «некоторый набор инструментов с общим подходом». Одни пользуются тем что есть, другие пишут инструменты под _свои_ задачи (и я вот сейчас), результат по определению не универсален.

Что реально все так плохо ?

И раз все Software Architecture-книги, уроки и конференции у O'Reilly, всё о том же, о Java, то все классические проблемы должны быть описаны, решены и изложены в учебниках для первокуров.

Ну так книги те пишут теоретики из универа, покупают ленивые сениоры, а код в продакшен пишут забитые джуниоры. :)

реально все так плохо ?

«так»? я думаю все даже чуть хуже ))

мы хотим управлялку и мы вроде догадываемся что ей можно быть многопоточной. но в многопоточность мы не умеем. что делать? запустить рядом 4 управлялки! ))

Но с кем не бывает, и в конце концов у нас же теперь есть systemd, который с подобным справляется на раз. Странно, конечно, что компания производитель серверного ПО не умеет его настраивать и запускать, но может быть это частный случай?

Серверы не только на линуксе работают, как и Java. И линукс без systemd - обычное дело. Так что универсальный метод всё равно нужен в принципе.

рекомендованный Atlassian init-скрипт для Jira делает ни много ни мало killall java.

А ты что хотела от энтерпрайза и от java? Что будет всё прямо и грамотно сделано? Фиг там. Энтерпрайз - это не качество, а сертификаты, подписка на техподдержку и бумажки, в которых говорится, что всё нормально будет работать. На деле бывает даже работает и не требует лишних вмешательств в процессе работы... но ценой дичайших костылей и подпорок. Именно поэтому энтерпрайз всегда был неповоротливым и страдал гигантоманией. Именно поэтому вместо оптимизации софта в энтерпрайзе всегда одно направление повышения производительности: купить железо мощнее или добавить дополнительное.