Да, улыбаемся и пашем)
На самом деле в моей практике есть случаи, когда работу принимают с огромной благодарностью и энтузиазмом. Но это скорее исключения. Например, в одном крупном банке инициатором контракта был отдел тестирования ПО для ДБО ЮЛ. Там вся работа тестировщиков была только «врукопашную». Мы пришли целой командой с автоматизаторами и нагрузочниками. И нам помогали всеми силами и возможностями. Заказчик остался очень доволен результатами.
В идеале я вообще хотел бы не знать, кто у нас там девопс. Как, например, я не знаю, кто у нас в фирме настраивает wifi, потому что мне никогда не приходилось к ним обращаться.
Не берусь судить об организации DevOps в вашей компании, но невозможно получить DevOps и не общаться с теми, кто его реализует. Мы просто не сможем узнать, что у разработчиков в головах. Я не могу построить пайплайн без участия девелопера: нужно знать тысячу мелочей, которые необходимо учитывать при сборке и деплое.
Хотя вынуждать разработчиков самостоятельно настраивать пайплайны и прочие инструменты, а самим (DevOps-инженерам) выступать в качестве консультантов — немного странно. На мой взгляд.
Чтобы погрузиться в DevOps, нужно прокачиваться, пробовать разные инструменты и задавать себе примерно такие вопросы:
Почему Jenkins? Что такое Jenkins? В чём практическая разница решения аналогичной задачи в Jenkins, GitLab CI, TeamСity?
Какой результат нужен руководству, когда ставит мне какую-либо задачу?
Есть ли какие-то альтернативные варианты?
Каковы при этом будут финансовые и временные затраты?
Как только самостоятельно начнете искать ответы на них (обычно сквозь боль и полученный опыт), то станете видеть общую картину процессов. Это и есть «путь DevOps».
Kubernetes стремится стать отраслевым стандартом, но эта цель еще далека. А его рыночная ниша — веб-приложения. К тому же, это не «серебряная пуля». Есть куча кластерных приложений, которые в ближайшее время (а может и никогда) не будут адаптированы под Kubernetes. В основном это различные enterprise-продукты. Например, SAP или 1С:ERP. И аналогичных клиент-серверных приложений великое множество.
Здравствуйте. Простого рецепта здесь, к сожалению, нет. Пока в вашей компании не появится DevOps (SRE) Engineer — сложившуюся ситуацию изменить будет довольно сложно.
На самом деле в моей практике есть случаи, когда работу принимают с огромной благодарностью и энтузиазмом. Но это скорее исключения. Например, в одном крупном банке инициатором контракта был отдел тестирования ПО для ДБО ЮЛ. Там вся работа тестировщиков была только «врукопашную». Мы пришли целой командой с автоматизаторами и нагрузочниками. И нам помогали всеми силами и возможностями. Заказчик остался очень доволен результатами.
Не берусь судить об организации DevOps в вашей компании, но невозможно получить DevOps и не общаться с теми, кто его реализует. Мы просто не сможем узнать, что у разработчиков в головах. Я не могу построить пайплайн без участия девелопера: нужно знать тысячу мелочей, которые необходимо учитывать при сборке и деплое.
Хотя вынуждать разработчиков самостоятельно настраивать пайплайны и прочие инструменты, а самим (DevOps-инженерам) выступать в качестве консультантов — немного странно. На мой взгляд.
Почему Jenkins? Что такое Jenkins? В чём практическая разница решения аналогичной задачи в Jenkins, GitLab CI, TeamСity?
Какой результат нужен руководству, когда ставит мне какую-либо задачу?
Есть ли какие-то альтернативные варианты?
Каковы при этом будут финансовые и временные затраты?
Как только самостоятельно начнете искать ответы на них (обычно сквозь боль и полученный опыт), то станете видеть общую картину процессов. Это и есть «путь DevOps».