Предисловие
Данная статья очень субъективна и основана на моём опыте в ИТ-индустрии (Я разработчик с 10-и летним стажем и опытом работы в различных проектах, командах и странах (Казахстан, Канада)). Уверен, что многие не поддержат мою точку зрения и могут назвать эту статью «плачем динозвара», но всё-же хочу поделиться ею…
Что такое DevOps
Согласно википедии DevOps набор практик, нацеленных на активное взаимодействие специалистов по разработке со специалистами по информационно-технологическому обслуживанию и взаимную интеграцию их рабочих процессов друг в друга. Т.е. это попытка масштабировать Agile весь процесс разработки ПО включая внедрение и сопровождение. Основное назначение DevOps-а — увеличение частоты релизов и повышение ответственности команды за продукт. Звучит идеально… как и любые маркетинговые слоганы…
С моей точки зрения основная задача DevOps — снижение затрат для бизнеса (что хорошо, но часто это идёт в ущерб качеству продукта).
Как DevOps убивает качество
Если вернуться в 90-ые и 00-е, то для создания продукта необходимо было несколько ролей в команде: аналитик, проектный менеджер, разработчик и тестировщик и внедренец. Каждая из этих ролей важна для создания качественного продукта: аналитик собирает требования и ограждает разработчиков от излишнего взаимодействия с заказчиком/пользователями, менеджер координирует работу команды и решает организационные и финансовые вопросы, разработчик — пишет код и правит баги, тестировшик эти баги находит и проверяет соответствие требованиям, внедренец — устанавливает ПО и является первой линией поддержки пользователей, огорождая разработчиков от лишних вопросов. Эта система хоть и слегка громоздка, но в ней есть чёткое разделение ролей в команде и новый функционал проходит через несколько человек, что повышает качество и позволяет взглянуть на проблему с нескольких точек зрения, что в результате даёт хороший и стабильный результат.
В 2000ых на смену этому подходу пришёл Agile, который с одной стороны больше вовлёк заказчиков в разработку, с другой стороны сильно уменьшил или вырезал роль аналитиков и проектных менеджеров. При этом внедрение осталось обособленным от основной части команды. Постепенно развёрнутые постановки стали заменяться фичами в бэклоге. Как разработчик, я всё-же больше люблю Agile, чем не люблю. Он повысил качество взаимодействия членов команды и вовлёк заказчика в процесс. Основным недостатком этого подхода стало потеря виденья проекта в целом. Т.е. понятие цельного продукта было заменено на набор фич, что повлекло к первому провалу в качестве. Разработка стала представлять собой лоскутное одеяло, когда новая фича прибивалась гвоздями к существующей и в результате система теряла целостность (хотя эта проблема не существует в командах с хорошими архитекторами/аналитиками, т.к. контроль позволяет избежать подобных проблем).
Сейчас Agile превращается в DevOps. Под слоганом повышения ответственности за продукт из команд почти полностью выпиливается тестирование, а внедрение существенно урезается и превращается в часть разработки. Роль разработчика повышается, но фактически в команде остаются только они, а само тестирование частично уходит в автоматизацию, частично ложится на плечи бета-тестеров и заказчиков. Сейчас многие компании (в особенности на Западе, где стоимость рабочей силы намного выше) с гордостью заявляют, что у них в командах нет тестировщиков, а разработчики владеют продуктом и отвечают за его качество. Но в чём же тут проблема?
Изначально продукт проходил несколько стадий контроля качества: сначала аналитик отфильтровывал требования заказчика и продумывал реализацию, потом разработчик проверял постановку и взаимодействовал с аналитиком чтобы улучшить её. Далее в ходе реализации рождались идеи по улучшению и они добавлялись в работу. Потом тестировщик проверял продукт и исправлялись ошибки. Далее аналитик демонстрировал работу заказчику и устранялись замечания.
Теперь есть только фича в бэклоге, разработанный функционал и автотесты и приёмка заказчиком (если он есть). Фактически фичей владеет только один человек и больше нет того уровня взаимодействия в команде.
Проблема DevOps в разработчиках. Они не способны качественно проанализировать требования и протестировать результат, т.к. они смотрят на продукт через призму кода, а не с точки зрения пользователей. Поэтому и качество программных продуктов за последнее время сильно упало и они стали менее удобными для пользователей (взять к примеру последнюю версию Skype, хотя примеров намного больше...).
Есть ли решение?
С моей точки зрения — решение есть, и оно достаточно простое. Нам нужно сохранить роли аналитиков, тестировщиков и внедрения в команде. Разделение труда ведёт к повышению качества и производительности (вспомните Стаханова и его идею разделения труда в шахте). Притом всё это легко интерировать в процесс DevOps. Вот моя идея: аналитики собирают требования клиентов и заказчиков и являются product-owner-ами для разработчиков, роль тестировщика и разработчика понятна, внедрение либо сливается с аналитиками, либо тесно с ним взаимодействует (тем самым замыкая цикл DevOps-а). От DevOps-а остаётся высокая степень автоматизации тестирования и внедрения, постоянное наличие стабильной версии продукта и частота релизов (вернее я бы сказал, что каждый билд — это релиз в данном случае). Ещё одно важное правило — быть клиентоориентированным и клиенто-центричным. Т.е. потребности клиентов должны быть превыше всего. Как не странно оба этих принциа успешно используются уже много лет в таких аутсорс компаниях, как EPAM (привет бывшим коллегам!) и отлично себя зарекомендовали там. Правда раньше автоматизация не была так развита, но надеюсь они восполнили уже этот пробел…
Комментарии (43)
azShoo
23.02.2018 23:25+3Во первых, обеспечение качества это не (только) тестирование. И тем более это не только ручное тестирование.
ДевОпс практики никак не ограничивают обеспечения качества, более того, правильно построенный процесс должен не только помогать бесконечно, быстро и прозрачно деливерить, но так же просто, быстро и безболезненно оценивать результаты релиза и, при малейшей необходимости, безболезненно откатываться.
Это то, что называется мониторингом и управлением качеством. QA инженеры неистово радуются такому.
Теперь по поводу ручного тестирования, его смерти и смещения в автоматизацию.
Первое: Автоматизация заменяет регрессионное ручное тестирование.
Это как раз те самые тесты, которые точно так же идут по заранее расписанным сценариям и точно так же, как и автотесты, пропускают всё, что ими не покрыто.
Это регулярно повторяемая, однообразная и не слишком интересная работа — то, что стоит автоматизировать всегда и при любой возможности.
Это освобождает ресурсы вашего отдела тестирования для исследовательского тестирования и тестирования методом свободного поиска. Как раз тех видов тестирования, где нужны интуиция, чувство прекрасного, здравый смысл и аналитические способности. Словом, всё то, что может человек, но не может скрипт написанный человеком.
Убивает ручное тестирование вовсе не ДевОпс, а потребности бизнеса и реалии рынка.
Ручное тестирование убивает скорость.
Сейчас даже у SPA для продажи носков такое количество ручек, состояний и внешних интеграций, что тестировать его руками — долго и неэффективно.
А делать кодфриз на неделю, что бы хорошенько всё оттестить не нужно примерно никому.
В то же время инженеры по тестированию — ограниченный, дорого и плохо масштабируемый ресурс.
Автотесты, в свою очередь, масштабируются очень просто и стоят относительно недорого.
Ну и скопом отвечу на ваши комментарии выше:
1) «Традиционный QA» отлично себя чувствует в полном CI\CD окружении. Потому что тестирование — один из этапов CI\CD.
Размазывание ответственности за качество на всю команду это то, за что будет неистово топить любой адекватный QA инженер. И этот тезис появился задолго до того, как девопс практики вошли в моду.
Может ли команда, следующая devops практикам существовать без QA Engineer как выделенной роли? Да, может.
Значит ли это, что там не будет QA, QC и тестирования как набора активностей? Нет, не значит.
Кажется у человека, на которого вы ссылаетесь, просто каша в голове из понятий.
2) Интеграционное и регрессионное тестирование — отлично поддается автоматизации. Это тривиальнейшая инженерная задача, которой за месяц обучается человек, раньше не писавший код вообще.
Это полтора прикладных инструмента, три паттерна и совершенно типовые архитектурные решения.
3) Код автотестов может содержать ошибки. Это так. Точно так же, как ошибками может обладать документация для тестирования.
Но тут есть одна ключевая разница: автотесты ведут себя одинаково всегда. Вы можете бесконечно расширять их набор, увеличивая покрытие, и их поведение не будет меняться от того, что вам понадобилось прогнать регрессионный набор тестов 12 раз подряд в ночь с пятницы на субботу.
Ручное тестирование всегда обладает человеческим фактором. В случае регрессионного и функционального тестирования — это огромный минус. Потому что глаз замыливается, внимательность может падать, а прогонять нон-стопом регрессионные тесты — это своего рода пытка.
Меняется ли тестирование и QA? Да, меняется.
Происходит ли это за счет популяризации девопс практик и инструментов? Да, в том числе.
Приводит ли это к смерти тестирования? Нет, не приводит. Это приводит к тому, что в тестировании начинают использовать код там, где код эффективнее, оставляя человеку те области, где он (пока что) выигрывает.
P.S. И да, я работаю QA инженером и прекрасно вижу, что происходит на QA-рынке.
Никакой смертью QA там и не пахнет. Зато действительно появляется всё больше компаний, которые понимают, что просто посадить 10 тестировщиков что бы они нон-стопом гоняли одни и те же тесты из релиза в релиз — недостаточно для обеспечения качества продукта.zenkz Автор
23.02.2018 23:37Спасибо за комментарий. Очень полезное дополение к статье и взгляд со стороны QA. К сожалению очень часто внедряют не правильный DevOps, а «DevOps», когда от него берётся то, что сокращает затраты, но не берётся то, что эти затраты повышает. Например, попытки внедрения DevOps во взрослых проектах с монолитной структурой и не покрытых тестами. Убираются «ручные» тестировщики, но не заменяются специалистами по QA-автоматизации и т.д. Т.е. если вы пишите новый проект, готовы вложиться в TDD и автоматизацию, используете микросервисы или другую модульную архитектуру, то DevOps может быть отличным выбором для вас, но если у вас легаси-проект, то DevOps с лёгкостью убъёт его.
azShoo
23.02.2018 23:47Ещё раз. Как таковой DevOps ничего не убивает.
Любые изменения в процессах, будь то внедрение аджайла, девопс практик, или ещё чего-нибудь могут убить проект.
Я точно так же видел проекты, которые загибались под гнетом тестирования. Просто потому, что продукт требовал быстрой поставки в продакшен, простых но быстрых изменений, проверки гипотез на проде и прочего.
А регрессия на нем шла в ручную в среднем три дня.
Потом там находились баги, они правились, и регрессировали ещё три дня.
Потом всё таки выкатывались в прод, находили баг в проде, и выпускали три дня хотфикс.
На развитии продукта в такой схеме можно просто поставить крест и разойтись по домам.
В России всё плохо с QA. В принципе ОЧЕНЬ плохо.
Компаний, которые у себя внутри держат не специалистов по тестированию, а QA инженеров — предельно мало (в Питере, например, их можно по пальцам посчитать).
И естественно, внедрение ДевОпс практик в команде, где единственным гарантом хоть какой-то работоспособности приложения является то, что N человек X часов гонят тесты — не приведет ни к чему хорошему.
Не потому, что ДевОпс это плохо. А потому, что ДевОпс призван ускорять деливеринг. А в таких условиях ускорять его нереально.
Точно так же внедрение аджайла в компании, где никто ничего не может без четко расписанного ТЗ и микроменеджмента — убьет всё нафиг. Но это не значит, что аджайл — это зло.
Просто любая методология, практика разработки или инструмент требует определенных условий, для её использования.
Но всегда есть карго культ, когда люди тупо копируют практики у успешных товарищей по отрасли и думают, что это решит все их проблемы.
Но это не изъян практик, это изъян людей.zenkz Автор
23.02.2018 23:56Три дня на регрессию — это очень неплохо. В Канаде сталкивался с ситуациями когда регрессионное тестирование занимало недели и все ресурсы команды.
А так — да, девопс не убивает — убивают карго-культы.azShoo
24.02.2018 12:53Всё сильно зависит от специфики.
Если вы выпускаете картриджи для нинтендо, то 3 дня фриза и тестирования — отличный результат. Потому что риски высокие, откатиться просто так нельзя, багфиксы не выкатишь и вот это всё.
3 дня регрессии для продукта, в котором обновление которого у всех клиентов занимает 10 минут — неприлично много.
Веб, клиент-серверные приложения десктоп-приложения, вот это всё. Вы можете выкатывать и откатывать фиксы, управлять версионностью, мониторить качество продукта и пользовательский опыт.
Нон стопом, быстро и безболезненно. Вам выгоднее и пользователям выгоднее получить полезную нагрузку ASAP, пусть даже сначала она станет полезной для 80% пользователей, потом для 90, потом для всех.
Даже в мобильных приложениях, где с принудительным обновлением клиентов всё относительно плохо, сейчас стараются делать всё, что бы можно было максимально гибко изменять поведение приложения не меняя клиент.
Разработка ускоряется, никто не готов работать по вотерфоллу где каждый этап водопада занимает месяц. Это не выгодно, не эффективно и не нужно ни разработчикам, ни заказчикам, ни пользователям.
Есть отдельные категории продуктов, где цена ошибки слишком высока, что бы от этого можно было полностью уйти, но таких продуктов — реальный минимум.
JC_IIB
24.02.2018 01:05(Я разработчик с 10-и летним стажем [..] Уверен, что многие не поддержат мою точку зрения и могут назвать эту статью «плачем динозвара»,
Рановато (лет на 20 точно как) вы на себя лычку «динозавра» примеряете.
Сейчас Agile превращается в DevOps.
Шта???
lxsmkv
24.02.2018 02:47Я для себя я определяю DevOps как «логистика в сфере разработки ПО». Чтобы нужные артефакты попали в нужное место в нужное время. И произросло оно из необходимости централизировать и специализировать эту область деятельности. Грубо говоря, десять лет назад можно было обойтись скриптиком на локальной машине, при сегодняшних масштабах разработки, аутсорсом и пр. это жизненная необходимость которую я не могу поставить под вопрос.
Для примера:
У нас чтобы разработчик увидел свой код в сборке (в продукте) может пройти два дня. Потому что некоторые слои программы собираются отдельно и, если между ними есть зависимости, их нельзя интегрировать одновременно.
В проекте задействовано порядка 200 разработчиков, представляете эффект от улучшения логистики?
Перейду к следующему пункту.
Проблема DevOps в разработчиках. Они не способны качественно проанализировать требования и протестировать результат, т.к. они смотрят на продукт через призму кода, а не с точки зрения пользователей. Поэтому и качество программных продуктов за последнее время сильно упало и они стали менее удобными для пользователей (взять к примеру последнюю версию Skype, хотя примеров намного больше...).
Нет, они способны, им не дают для этого адекватных сроков. Заказчик хочет быстро много и дешево. И чтобы ему сверху не прилетело. Например судебный иск на пять миллиардов евро. Ну и не надо забывать что качественные кадры тоже редкость — спрос большой, качество низкое, берут любых.
Ну и программисты тоже народ порой своеобразный:
8. Многие из вас знакомы с достоинствами программиста. Их всего три, и разумеется это: лень, нетерпеливость и гордыня.
Из "50 цитат о программировании всех времён"
— Larry Wall
Да, некоторым хочется сказать — «не умничай, а просто делай».
У нас приложение состоит из слоев, и часто так получается, что все таски по фиче закрыты, а фича работает наполовину. Но каждый свою часть работы посчитал законченной, потому что «ну если у них там не готово то это не мои проблемы».Получается как у Райкина: «Кто сшил костюм?» Даже мне приходится так делать (моя задача автоматизация приемочных тестов — на что смог написать автоматизацию на то и написал, не вечно же ждать пока все готово будет). А общая проблема в неадекватных требованиях заказчика. A фирма соглашается на условия заказчика потому что жить на что-то надо. А заказчик за что платит, то и имеет. Если заказчик десять раз в год меняет свои хотелки — так будет выглядеть и код и конечный продукт. Как франкенштейн. Потом заказчик понимает, что время экспериментов подошло к концу и бюджет тоже — пора на рынок, просят одеть франкенштейна во что нибудь яркое и красивое. Вот вам новый Skype.
Вообще по современным тенденциям хочу сказать:
Когда твой компас — страх за собственную задницу — ты точно будешь двигаться не в том направлении.
Когда твой компас — жажда денежной выгоды — ты будешь двигаться не в том направлении.
Но если твой компас — это пользователь, которого ты хочешь сделать немного счастливее, ты придешь к своему пользователю.
— © Я
WinPooh73
24.02.2018 12:23+1> Но если твой компас — это пользователь, которого ты хочешь сделать немного счастливее, ты придешь к своему пользователю.
Станешь ли ты при этом счастливее сам, вопрос остаётся открытым.lxsmkv
24.02.2018 15:54Мне кажется, только когда ты приносишь радость другим ты становишься счастливее сам.
Дело в том, что разработчики, как правило никак не участвуют в создании идеи продукта. Они только исполняют необходимую для воплощения чьих-то замыслов работу. Именно поэтому люди уходят в стартапы.
Надо видеть свой вклад в продукт. У нас как-то делали опрос, типа, насколько вы идентифицируете себя с продуктом который делаете, и показатель по этому параметру был очень низкий. Я вот только не помню по всей фирме или это специфика нашего проекта. Наддо будет спросить в отделе.
Я вот, нахожу баги, работа такая, и радуюсь, чем выше приоритет бага тем больше я радуюсь — а тимлид с точностью наоборот. Он умом понимает, что это важная работа, но радоваться багам не умеет.VolCh
25.02.2018 17:15Возможно умеет, например, найдя баг у конкурентов. :) Но в целом зависит от точки зрения на баг: "обнаружив баг, мы узнали, что уже сделали жизнь пользователей хуже" против "обнаружив баг, мы нашли простую возможность сделать жизнь пользователя лучше".
viru0
24.02.2018 06:26-1Тут все от компании зависит. Видел(работал) там где DevOps'ы не как не конфликтовали ни с QA ни с разрабами и все работало как часы. Выделены роли были четко. Разница между DevOps и классическим админом было в том, что он(DevOps) мог запросто посмотреть в код существующего проекта и разбить его скажем на 2 микросервиса(не обязательно своими руками, но он понимал в чем соль самого web приложения), все запаковать в контейнер и пустить в продакшн.
И видел(работал) когда все роли смешивались в одну (ты как разраб и за качество и за деплой отвечаешь), стоит ли говорить что во втором случае качество было ниже плинтуса, вечно винили во всем разрабов. А если сидишь пол дня тестишь на всех платформах фичу, то тоже претензии. (Сбежал из второй конторы очень быстро)
garex
24.02.2018 07:11+3DevOps — лигр админа и девелопера. QA здесь причём? Основная цель QA — качество. И если QA-шнику нужна инфраструктура, то он её с девопса и спросит. Те же автотесты (не-юнит) пишутся всё равно QA-шниками. Не понял посыла статьи.
TheDeadOne
24.02.2018 10:11+1На мой взгляд, корень проблемы в том, что DevOps — это на сегодняшний день buzzword, который каждый понимает по-своему. По-моему, правильный DevOps это когда на проекте есть аналитики, тестировщики, несколько групп разработчиков, админы, сетевики и есть группа специалистов умеющая, всё то, что умеют специалисты вышеперечисленных групп. Пусть даже поверхностно, главное — чтобы понимали процессы в каждой группе.
Suvitruf
24.02.2018 14:57Меня забавляет другое. В целом, если утрировать, то DevOps — это админ + девелопер. Если говорить про это именно как про методику, то это взаимодействие админов и разработчиков.
Это я к чему. Так было, на моей памяти всегда, все работали сообща. Но N-ное количество назад появилось это надоедливое слово DevOps и отчего такое внимание привлекло. Не понимаю.
lair
24.02.2018 15:51Так было, на моей памяти всегда, все работали сообща.
То есть вы никогда не встречались с "ну, мы написали, теперь вы сами ставьте и управляйте"? Счастливый человек.
SirEdvin
24.02.2018 19:05Ну, для начала стоит заметить, что никто особо не представляет, что такое этот DevOps. В общем случае это представляется как слом стены перекидывания ответственности между Dev, Ops, и, внезапно, QA и Sec командами, если они есть.
То, что многие относят к повышению доставки все-таки на мой взгляд не DevOps, а именно CI/CD практики.
И не совсем понятно, как идея, направленная на то, что неважно насколько ты узконаправленный специалист, ты должен хотя бы немного думать о других может что-то разрушать.
В общем случае это означает что разработчик, когда пишет код должен немного думать о том, как его будет удобно протестировать, деплоить и мониторить. Ops должен в свою очередь предоставлять и разрабатывать инфраструктуру под приложение, для чего должен понимать как оно работать и что ему нужно, а QA должен приблизительно понимать как это все работает и что где можно потыкать. И как не удивительно, это все направленно на повышение качества.
С другой стороны современное ПО просто настолько сложное и засыпанное абстракциями по всем местам, а опытных программистов, которые еще могут работать с современными технологиями, а не только php 4/python2.3/вставь старую технологию становится все меньше, то и получаем дефицит квалифицированных кадров и как следствие плохое качество в ПО.
PerlPower
24.02.2018 22:34Ну, для начала стоит заметить, что никто особо не представляет, что такое этот DevOps
На этом можно и закончить. Потому что если спросить у 10 разных разработчиков что это такое, не как определение в википедии, а как реальный набор практик для конкретного проекта, то едва ли мы получим одинаковые ответы хотя бы в половине случаев.
Scf
25.02.2018 09:36Нет, нет, нет.
Agile, DevOps — это естественное развитие процессов разработки, уменьшающее время между появлением требования и выкатыванием его в продакшн.
Давайте и я дам свое определение как практик. DevOps — это набор практик автоматизации типичных задач администрирования с целью максимального ускорения их выполнения и минимизации ошибок.
VolCh
25.02.2018 17:32Автоматизация типичных задач администрирования лишь один из способов решения основной задачи DevOps: сделать разработку, поставку и эксплуатацию если не одним процессом, то очень согласованными процессами. И всё это с целью ускорения доставки фич и багфиксов до пользователей.
С точки зрения DevOps особо без разницы автоматизирован процесс билда и деплоя или нет, если между разработчиками, релиз-инженерами и админами нет чёткого понимания, что каждая из сторон ждёт друг от друга и готова дать друг другу. Автоматизация — это уже оптимизация процессов, но сначала их нужно построить.
Singaporian
25.02.2018 10:25Отличная статья и отличные мысли, на которые я раньше не обращал внимание. Однако, давайте теперь повангуем.
Из статьи отчетливо видно, что в DevOps оставили ответственность перед Dev и перед Ops, а остальных (аналитика, архитектора, тестировщика) выкинули на обочину современности. Причем, чем выше скорость разработки, тем меньше они участвуют — это ответ всем тем, кто выше заявляет, что у них не так. У вас, парни, просто медленный проект. Архитекторами всегда топят печку паровоза, чтобы высрать технический долг из выхлопной трубы.
Итак, те, кто захочет повышать качество продукта, приклеют обратно аналитика к DevOps. Не силен в сокращениях, поэтому назовем это AnalDevOps. Потом вернут архитектора. AnalArchDevOps. Потом тестировщикам дадут время сделать работу качественно — AnalArchDevQAOps.
Короче, они вернутся в то, что было до DevOps, сохранив многие аспекты этого DevOps, типа унификации сред и атомарно-модульной структуры приложения.
При этом сама этимология слова DevOps уйдет.
В это время рынок живет своей жизнью. И выигрывают на нем те, кто быстрее схватил клиента и уже на месте перед ним танцует и парит ему мозг. Парни, которые организовали качество — сдохнут. Парни, которые удалили всех из цепочки, оставив только разработчиков, соберут миллионы за свой быдлокод.
Поэтому все разговоры про низкое качество DevOps, конечно, справедливы. Однако, релевантны ли?lair
25.02.2018 10:53-1Из статьи отчетливо видно, что в DevOps оставили ответственность перед Dev и перед Ops, а остальных (аналитика, архитектора, тестировщика) выкинули на обочину современности.
Важное уточнение: из статьи отчетливо видно, что в DevOps, как его понимают в статье, оставили [...] выкинули [...].
ybalt
25.02.2018 11:57Забавная статья, наверное в середине прошлого века писали что-то похожее
«Не люблю конвейер, убивает дух сборки вручную»
Наверное проблема в определении самого понятия, для кого-то это модное слово, для кого-то убийца тестирования, а для кого-то процесс автоматизации рутинных задач и выстраивания процесса разработки в виде каких-то определенных, описанных кодом схем.
Грубо говоря, лично для меня, DevOps это про автоматизацию всего того, что делается вручную — от запуска сборки до деплоя на сервер. Это ни в какой мере не заменяет и не убивает необходимые шаги, вроде тестирования, но позволяет вывести операции (Ops) на качественно новый уровень и представить их в виде кода и сопутствующих ему практик (Dev)
Ipeacocks
25.02.2018 22:14> взять к примеру последнюю версию Skype, хотя примеров намного больше
Скайп и подобные вещи просто пошли путем удешевления переходом на веб-технологии. Т.е. не думаю, что девопсы тут виноваты.
Throwable
26.02.2018 15:07-1Проблема DevOps в разработчиках. Они не способны качественно проанализировать требования и протестировать результат, т.к. они смотрят на продукт через призму кода, а не с точки зрения пользователей.
Нифигасе заявление! Да практически все идеи генерятся девелоперами! Просто в большинстве компаний сложилась такая номенклатурная организация, что между пользователем и девелопером стоят люди, называющие себя аналитиками, которые практически никогда в жизни не писали код. Они слабо представляют сам процесс разработки, архитектуры и огранизации системы, возможности кода и трудозатраты, и тем не менее сидят на своем месте и получают зарплаты. Это такие как Tom Smykovski из легендарного Office Space, который заявлял: "I have people skills":
Нам нужно сохранить роли аналитиков, тестировщиков и внедрения в команде. Разделение труда ведёт к повышению качества и производительности (вспомните Стаханова и его идею разделения труда в шахте)
Вы упускаете ОЧЕНЬ важный момент: разделение труда работает только в тех системах, где взаимодействие между членами минимально, и упрощено насколько это возможно, а сам труд реально разделяем — тогда это работает. Инженерная же идея, тем более достаточно сложная, очень плохо скалируется по головам. Если команда девелоперов придумала и закодила функционал, нужно будет объяснять все детали реализации команде тестировщиков, чтобы те, из того, что они поняли, смогли написать кое-какие тесты. А кто лучше сможет написать тесты и покрыть больше кейсов, чем сами девелоперы?
Из негативных эффектов разделения труда — это круговая порука и сбагривание ответственности. В девопсе же девелопер несет ответственность до конца.
P.S. Говоря о девопсе, вы полностью упустили сам "опс", например команду админов, которая файерволом стоит между девелоперами и продакшном и фактически не дает девелоперам видеть, что происходит с их кодом на сервере.
lair
26.02.2018 15:10Если команда девелоперов придумала и закодила функционал, нужно будет объяснять все детали реализации команде тестировщиков, чтобы те, из того, что они поняли, смогли написать кое-какие тесты.
А зачем объяснять тестировщикам детали реализации, если тестировать надо ожидаемое поведение в первую очередь?
lair
Что-то я не понимаю, где вы нашли такое понимание DevOps.
zenkz Автор
Ну например вот: devops.com/devops-killed-qa (На английском)
Essentially, the traditional QA cannot work in a full CI/CD environment. In older structures, the responsibility for software quality was in the hands of QA. Today, it’s part of the DevOps culture and methodology—the developers now own the responsibility rather than a separate entity within the organization.
Традиционный QA не может работать в полном CI/CD окружении. В старых структурах ответственность за качество ПО было в руках QA. Сегодня это часть культуры DevOps — разработчик сейчас владеет ответственностью в отличии от отдельной части внутри оргранизации.
To run a proper DevOps operation, you cannot have QA at all.
Следуя DevOps вы можете не иметь QA вообще.
asm0dey
QA — это не обезьянки, которые на кнопки тыкают. В первую очередь жто люди, определяющие методологию тестирования. Неплохо бы чтобы они могли написанное автоматизировать, но на худой конец автоматизировать могут и разработчики. А уже автотесты встраиваются в CD пайплайн.
saboteur_kiev
Девопс связан с тем, что разработка продукта сейчас стала значительно сложнее как организационно, так и технически. Следовательно есть куча инструментов, которые кто-то должен связать в SDLC как организационно, так и технически.
Можно настроить девопс практику и для waterfall, нет никакой однобокой привязанности DevOps и Agile.
Основная техническая задача — автоматизация и интеграция различных удобных систем (анализ кода, ускорение и автоматизация сборки, CI и ревью, в том числе и тестирование), и так далее. А так, как даже самые похожие проекты могут иметь свои критичные нюансы, практику сложно записать в несколько пунктов — нужен живой человек, который подстроит все в конкретном проекте.
VolCh
Причём достаточно хорошо разбирающийся и в разработке, и в эксплуатации. В частности, понимающий на какой стороне проще основную часть работ по интеграции делать. Банальное, то ли читать параметры конфигурации приложения из переменных окружения, то ли из текстовых конфигов.
Paskin
Вышеприведенный текст — лучшее доказательство что любая идея доведенная до абсурда, абсурдом же и станет. Не зря CI отделяется от CD — нигде не сказано что успешная интеграция должна сразу вызывать деплоймент на «боевые» системы. Во многих случаях это просто невозможно по юридическим, маркетинговым или другим причинам.
А по поводу Agile — он и должен работать как вы описали. Аналитики на основе анализа рынка и обратной связи с внедренцами формулируют и приоритизируют задачи для разработчиков (user stories).
zenkz Автор
Идея в том, что DevOps предполагает автоматизацию процессов тестирования, интеграции и публикации новых изменений. В этом процессе почти нет места ручному тестированию. Единственный сценарий — тестировать на боевых серверах, чтобы исправить ошибку в следущем билде. Также предполагается TDD и/или покрытие всего функционала автотестами. Но тут несколько проблем:
— интеграционное и регрессионное тестирование плохо поддаётся автоматизации
— автотесты всегда следуют одним и тем же сценариям, а ошибки может возникать в непокрытых сценариях (К примеру только при переходе с определённой страницы сайта).
— код автотестов также может содержать ошибки
VolCh
Спорно. И ручному тестированию есть место. И главная цель автотестов именно регресионное тестирование.
zenkz Автор
Главная цель автотестов — уменьшение рутинных задач для тестировщика и проверка основных и, наоборот, редких сценариев. К сожалению я бы не назвал то, что делают автотесты регрессионным тестированием — скорее это смоук-тесты (т.е. обнаружение явных проблем в продукте).
lair
Но почему?
MonkAlex
Значит это неправильные тесты. Пока тестами покрыта хоть какая то логика — регрессию они ловят отлично. Особенно это заметно в крупных и продолжительных во времени проектах.
VolCh
Ну так основная часть рутинного тестирования именно регрессионное. Новую фичу ну раз десять проверить нужно как новую, а потом сотни и тісячи раз проверять, что она не сломалась в процессе создания и(или) удаления других фич.
lair
Я сразу на оба комментария отвечу.
Здесь есть два важных слова: "traditional QA" и "full CD environment". Ни одно из них не DevOps, как ни странно.
И снова, это не DevOps предполагает, это CD предполагает (открываем Хамбла-Фарли, Continuos Delivery, 2011 год). И это логично, потому что вы не можете делать быстрые релизы, если вам нужно ручное ("традиционное", в понимании цитаты выше) тестирование. Вот только DevOps здесь снова ни при чем.
Да, в CD-среде традиционный QA с ручным тестированием работает неэффективно. Это не значит, что в CD-среде нет QA, это значит, что в CD-среде QA другой.
Это, кстати, неправда. CD позволяет ручное тестирование на соответствующей среде, столько раз, сколько нужно — просто сразу делается оговорка, что такое тестирование замедляет цикл. Компромис между одним и другим каждый выбирает для себя.
Интеграционное еще могу понять (хотя и оно автоматизируется успешно), но вот регрессионное, которое по определению предполагает повтор одних и тех же шагов на каждом билде, как раз первый кандидат на автоматизацию.
И чем вам тут поможет "традиционный QA"? Тем, что он кликает случайным образом?
… люди, которые делают тесты руками, ошибаются больше.
Но, снова повторюсь, DevOps — он не обязательно про CD (хотя обычно предполагает CD), он про то, чтобы команда разработки была прямо задействована в процессе обслуживания (начиная с развертывания) продукта.
ctacka
Простите конечно, но тестировщики тестируют не как на душу ляжет, а по тест-плану с тест-кейсами. Они же этот план и создают, основываясь на требованиях, явно или неявно сформулированных. То, что они потом это делают руками или автоматизируют скриптами, не меняет качества покрытия. Если сценарием тестирования не покрывается участок с ошибкой, то он и руками не будет простестирован, потому что он не покрыт сценарием.
Ваше утверждение, что регрессионное тестирование плохо поддаётся автоматизации просто ошибочно: оно гораздо лучше в автоматизированном виде, чем в ручном, потому что у вас всегда воспроизводятся все сценарии одинаково, что для регрессии просто супер важно.
Проблема в другом, как мне кажется: DevOps — это идеология, и принятие её (как и не принятие) лежит в иррациональной области. Это как с коммунизмом: само по себе ничего страшного, но почему-то потом у некоторых идеологов оказывается, что кибернетика и генетика ему противоречат. С DevOps тоже, есть условно маоисты-devops, есть троцкисты-DevOps, а есть вообще devops-чучхе.