Size: a a a

2020 February 08

I

Igor in DevOps
George Gaál
Когда тебе нужна поддержка от редхата + те доп компоненты, что в нем есть
То есть плюс-минус никогда?)
источник

AA

Artyom Abramovich in DevOps
Alexander
Я хз, при чем тут дженкинс, но ты сам давно придумывал язык под предметную область?
там нет groovy dsl?
источник

GG

George Gaál in DevOps
Igor
То есть плюс-минус никогда?)
Для тебя - да
источник

DS

Dmitry Sergeev in DevOps
Igor
То есть плюс-минус никогда?)
Там куча ништяков, почитай на сайте у них
источник

LB

Let Eat Bee in DevOps
Alexander
И, к слову, в DevOps DSL не нужны. Никто не делает так, что сначала придумывает язык для предметной области и лишь потом пытается его реализовать. Все берут привычный инструмент и пляшут от него, создавая набор функций, наиболее адекватно решающий задачу. Никто от языка не пляшет.
Мой аргумент в том, что если powershell становится тем самым привычным инструментом, то мучений в профессии станет сильно меньше. И может даже следующий ансибл не появится за ненадобностью
источник

A

Alexander in DevOps
Artyom Abramovich
там нет groovy dsl?
Groovy не dsl, в нем нет ничего специфичного для предметной области. Это просто скриптовый язык, который было удобно пришлепнуть к дженкинсу. Ну и занимались этим явно не devops-ы.
источник

I

Igor in DevOps
Dmitry Sergeev
Там куча ништяков, почитай на сайте у них
Не, я хочу ввести команду и получить полноценный кубер. Нафиг что-то ещё читать?
источник

A

Alexander in DevOps
Let Eat Bee
Мой аргумент в том, что если powershell становится тем самым привычным инструментом, то мучений в профессии станет сильно меньше. И может даже следующий ансибл не появится за ненадобностью
У меня такое ощущение, что за использование Заббикса точно такие же аргументы :)
источник

DS

Dmitry Sergeev in DevOps
Alexander
Groovy не dsl, в нем нет ничего специфичного для предметной области. Это просто скриптовый язык, который было удобно пришлепнуть к дженкинсу. Ну и занимались этим явно не devops-ы.
+++.
Но ты упускаешь один момент, у них есть декларативные пайпы, и это вполне себе DSL =) + jobDSL, jcasc
источник

LB

Let Eat Bee in DevOps
Igor
Ну окей. Взглянем с точки зрения разраба. Как изменится взаимодействие с шеллом?
Разрабы как раз и делают большинство ошибок в скриптах. Если скрипты на повершеле, то ошибок будет сильно меньше
источник

DB

Dmitry Burmistrov in DevOps
Ггг
источник

SP

Sergey Pechenko in DevOps
Let Eat Bee
Мой аргумент в том, что если powershell становится тем самым привычным инструментом, то мучений в профессии станет сильно меньше. И может даже следующий ансибл не появится за ненадобностью
Слушай, ты там как вообще? У тебя есть кому лоб потрогать тыльной сторонй кисти там, градусник подать? Жар, может?

Ну а если серьёзно - какой нафиг помершелл, на каких таких линукс-тачках ты его встречал искаропки?
источник

A

Alexander in DevOps
Dmitry Sergeev
+++.
Но ты упускаешь один момент, у них есть декларативные пайпы, и это вполне себе DSL =) + jobDSL, jcasc
Разве это не просто библиотеки функций для groovy?
источник

LB

Let Eat Bee in DevOps
Alexander
У меня такое ощущение, что за использование Заббикса точно такие же аргументы :)
Не знаю. У меня просто перед глазами git - когда все перестали страдать хернёй и сошлись на одном достаточно мощном инструменте вся экосистема полетела вверх
источник

DS

Dmitry Sergeev in DevOps
Igor
Не, я хочу ввести команду и получить полноценный кубер. Нафиг что-то ещё читать?
он не просто полноценный, а кубер + ништяки от редхата. О ништяках лучше почитать на сайте. Или спросить у юзающих их людей.
Например я слышал об отличном дашборде, роутах (как точки входа трафика), вроде всякие интеграции с LDAP из коробки и тому подобное
источник

I

Igor in DevOps
Dmitry Sergeev
Там куча ништяков, почитай на сайте у них
Если мне надо поднять затюненный КХ с постгресом, то как мне в этом помогут все их ништяки?
источник

DS

Dmitry Sergeev in DevOps
Igor
Если мне надо поднять затюненный КХ с постгресом, то как мне в этом помогут все их ништяки?
Тоже самое можно сказать про куб, и все что угодно. Это вообще не связанные вещи
источник

A

Alexander in DevOps
Let Eat Bee
Не знаю. У меня просто перед глазами git - когда все перестали страдать хернёй и сошлись на одном достаточно мощном инструменте вся экосистема полетела вверх
Гит решает проблемы (его для решения конкретных проблем и сделали), а повершелл их создает (по крайней мере, за пределами винды).
источник

DS

Dmitry Sergeev in DevOps
Alexander
Разве это не просто библиотеки функций для groovy?
ну DSL над groovy, да =). Но ничего не мешает юзать просто groovy конечно
источник

A

Alexander in DevOps
Потому что делали его для того, чтобы выставить в шелл дотнет, а не чтобы решать проблемы.
источник