DevOps это программисты, которые работают в очень маленьких компаниях и вынуждены ещё и админить? Разве у них возникают какие-то уникальные вопросы, которые не относятся ни к Development ни к Admin?
А причина в том, что времена, когда сначала отдел планирования пять лет планировал, потом отдел разработки полгода разрабатывал, потом отдел тестирования полгода тестировал, а потом отдел администрирования полгода выкатывал на прод, прошли. И планировать, разрабатывать, тестировать и выкатывать надо одновременно, на ходу меняя колеса.
ты все неправильно написала. девопсы это недопрограммисты и недоадмины призванные поддерживать кривые продукты полные багов, но тем не менее выкинутые на рынок с целью опередить конкурентов. А баги фиксят уже под крики ужасов кастомеров превращенных в доп. отдел тестирования.
И это верно. Поэтому DevOps - это не просто дать программисту админский пароль и сказать, чтобы всё было готово к вечеру, а тестеров вообще уволить за ненадобностью.
Это другая организация разработки, с другим набором инструментов. О которых и может быть, теоретически, отдельный раздел.
если кому интересно, вот список тем, которые будут обсуждаться в этом разделе.
кому совсем делать нехрен, может в ответе указать что и где можно было бы обсуждать.
iib
ansible tower
docker/kubernates
postman со всякими приблудами(monitor) и все подобное
jenkins
bitbucket/git
Да их не фиксит никто, а создают видимость работы с сообществом пользователей. И через год либо проект выкидывается, либо преобретает такие анальные Legal&Terms, что на юзеров просто кладется. Вот в этом и учатсвуют «девопсы». Тут впору вопрос о моральности ставить
И это верно. Поэтому DevOps - это не просто дать программисту админский пароль и сказать, чтобы всё было готово к вечеру, а тестеров вообще уволить за ненадобностью.
Это другая организация разработки, с другим набором инструментов. О которых и может быть, теоретически, отдельный раздел.
«DevOps — это подход». Это все слышали. А где-нибудь, собственно, сформулированы в явном виде основные положения этого подхода?
А то по итогам последних нескольких тредов про DevOps на ЛОРе начинает складываться стойкое впечатление, что DevOps — это что-то среднее между «пойди туда, не знаю куда и принеси то, не знаю что» и «Тем-Кого-Нельзя-Называть» :)
В результате половина людей считает, что DevOps — «это программисты, которые работают в очень маленьких компаниях и вынуждены ещё и админить» ( ZweiStein), а вторая половина считает, что DevOps — «это когда Docker и Kubernetes» ( dada).
А где-нибудь, собственно, сформулированы в явном виде основные положения этого подхода?
Пожалуй самый «классический» подход к этой теме сейчас изложен в SRE Book у Гугла. Они называют SRE реализацией идеи DevOps на практике.
Но на самом деле устоявшейся является собственно постановка проблемы. А методы и инструменты как эту проблему решать - нет.
С одной стороны это плохо, поскольку все делают что попало, критерии качества и успеха условны и т.п. С другой стороны поэтому и интересно обсуждать, делиться опытом и пытаться систематизировать.
Инструменты для devops - это отдельный разговор. Потому что под предлогом «упрощающей жизнь автоматизации» чего только не наизобретали.
Например можно сказать что контейнеризация сама по себе, как способ сохранения состояния между фазами разработки, тестирования и прода - это действительно DevOps, потому что разрыв между разработкой и запуском уменьшает.
При этом например docker swarm и толпа разработчиков начинающая оборачивать его своими make-скриптами - это анти-DevOps, потому что барьер между разработкой и работой в проде снова воспроизводит.
Хотя и то, и то - контейнеры.
И надо всё время напоминать себе и окружающим, что контейнеры, облака и автоматизация всего делаются не сами по себе, а для реализации devops-подхода. И если они этому подходу в данной конкретной ситуации противоречат - их делать не надо.
Как по мне, работа devops-a в каждой конторе формируется по своей линии.
В моем случае, есть несколько тимов, которые девелопят разное.
Т.е. для ребят, которые разрабатывают мобильное приложение будет чуток другой devops, чем для ребят, которые пилят модуль для tomcat.
Разные инструменты и разные flow. А есть еще несколько тимов pl/sql-щики, php-ники, iib-ники и т.д.
Плюс, обновления от нескольких вендоров.
Компания большая, нужно, что называется, «поставить на рельсы» вывод на продакшн.
Много народу из бизнеса все это дело тестирует.
В любом случае, как сказал alpha, тема живая.
Я не знаю насколько много тут devops, но я, как начинающий и имеющий к этому интерес, хотел бы иметь место где про все это можно было бы спросить.
Вот и подумал, почему не на лоре.
Что бы сильно не раздувать тему, скастую maxcom.
Решение все равно за ним.
Итак, devops — это когда ты вместо того, чтобы говорить «проблема на их стороне», или «я не админ, я программист» (или наоборот) — берёшь и разбираешься, помогаешь чем можешь.
Соответственно, те, кто считают devops ненужным — профнепригодны.
Это ещё что, мне рассказывали, как в одной конторе занимающейся тестированием пропал интернет и все сидели молча ждали, пока его починят. Начальник тестерам сделал замечание, что они должны были выяснить, где именно проблема, и сообщить админу, если он до сих пор не в курсе.
Видно человека, который не видел в глаза рабочего проекта.
Вот есть продукт, где ч(м)удаки-суперпрограммисты понаписали такого, что для выката новой версии в работу требуется 8 листов инструкции по ручной установке. Причем этим занимаются настоящие суперадмины по ночам в пятницу.
Конечно, нахрена им девопс. Они ж супер, не то что недо.
у меня, как у заказчика нет желания оплачивать суперадминов или непонятных девопсов или уборщиц с умением танцевать у шеста. По сути это все балласт не приносящий прибыль компании.
А в случае девопса этот кусок говна просто оконтейниривают сами пейсатели, да? Ну можно сэкономить на супер-админах, да, и чуть бабосов подкинуть из сэкономленного «девопсам», зато модно и молодежно.
Для бизнеса тут смысл только в экономии времени и бабла, а «девопсы» или кто-то еще появится — насрать вообще.
для выката новой версии в работу требуется 8 листов инструкции по ручной установке
Ну так это не софт уже, а говно какое-то.
У меня под основной проект есть две статейки для наших админов в вики: «Список текущих и потенциальных проблем» и «Тонкости обновления $product_name». В первой два пункта, один из которых — нефиксабельная с нашей стороны трабла сторонней софтины из поставки Астра Линукс, а вторая — просто позорище, которое таки закостыли, но на всякий случай отписали о ней в статью. А во второй целых шесть, но все они про конфигурацию, и почти все сводятся к включению новых фич, которые по-дефолту выключены.
И это всё.
Проект живой, активно используемый, приносит некоторую нефть. Сотни нефти нам не приносит (зато приносит заказчику), т.к. продукт сопутсвующий, но без него нефти не будет вовсе.
Тебя как заказчика никто не спросит кому и сколько надо платить на стороне выполняющей заказ. И что там тебе непонятно и кажется что айфоны на деревьях растут в готовом виде, упакованными - это твоё личное дело, и твоя личная ограниченность, которые с тобой никто не собирается обсуждать. Плати за заказ и иди гуляй.
А вот кто, как и что делает на стороне исполнителя - это интересная тема для разговора.