Pull to refresh

Comments 85

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

Что-то я не понимаю, где вы нашли такое понимание DevOps.

Ну например вот: 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 вообще.
QA — это не обезьянки, которые на кнопки тыкают. В первую очередь жто люди, определяющие методологию тестирования. Неплохо бы чтобы они могли написанное автоматизировать, но на худой конец автоматизировать могут и разработчики. А уже автотесты встраиваются в CD пайплайн.
Девопс связан с тем, что разработка продукта сейчас стала значительно сложнее как организационно, так и технически. Следовательно есть куча инструментов, которые кто-то должен связать в SDLC как организационно, так и технически.

Можно настроить девопс практику и для waterfall, нет никакой однобокой привязанности DevOps и Agile.

Основная техническая задача — автоматизация и интеграция различных удобных систем (анализ кода, ускорение и автоматизация сборки, CI и ревью, в том числе и тестирование), и так далее. А так, как даже самые похожие проекты могут иметь свои критичные нюансы, практику сложно записать в несколько пунктов — нужен живой человек, который подстроит все в конкретном проекте.

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

Вышеприведенный текст — лучшее доказательство что любая идея доведенная до абсурда, абсурдом же и станет. Не зря CI отделяется от CD — нигде не сказано что успешная интеграция должна сразу вызывать деплоймент на «боевые» системы. Во многих случаях это просто невозможно по юридическим, маркетинговым или другим причинам.
А по поводу Agile — он и должен работать как вы описали. Аналитики на основе анализа рынка и обратной связи с внедренцами формулируют и приоритизируют задачи для разработчиков (user stories).
Идея в том, что DevOps предполагает автоматизацию процессов тестирования, интеграции и публикации новых изменений. В этом процессе почти нет места ручному тестированию. Единственный сценарий — тестировать на боевых серверах, чтобы исправить ошибку в следущем билде. Также предполагается TDD и/или покрытие всего функционала автотестами. Но тут несколько проблем:
— интеграционное и регрессионное тестирование плохо поддаётся автоматизации
— автотесты всегда следуют одним и тем же сценариям, а ошибки может возникать в непокрытых сценариях (К примеру только при переходе с определённой страницы сайта).
— код автотестов также может содержать ошибки
Спорно. И ручному тестированию есть место. И главная цель автотестов именно регресионное тестирование.
Главная цель автотестов — уменьшение рутинных задач для тестировщика и проверка основных и, наоборот, редких сценариев. К сожалению я бы не назвал то, что делают автотесты регрессионным тестированием — скорее это смоук-тесты (т.е. обнаружение явных проблем в продукте).
К сожалению я бы не назвал то, что делают автотесты регрессионным тестированием

Но почему?

Значит это неправильные тесты. Пока тестами покрыта хоть какая то логика — регрессию они ловят отлично. Особенно это заметно в крупных и продолжительных во времени проектах.

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

Я сразу на оба комментария отвечу.


Essentially, the traditional QA cannot work in a full CI/CD environment.

Здесь есть два важных слова: "traditional QA" и "full CD environment". Ни одно из них не DevOps, как ни странно.


Идея в том, что DevOps предполагает автоматизацию процессов тестирования, интеграции и публикации новых изменений. В этом процессе почти нет места ручному тестированию.

И снова, это не DevOps предполагает, это CD предполагает (открываем Хамбла-Фарли, Continuos Delivery, 2011 год). И это логично, потому что вы не можете делать быстрые релизы, если вам нужно ручное ("традиционное", в понимании цитаты выше) тестирование. Вот только DevOps здесь снова ни при чем.


Да, в CD-среде традиционный QA с ручным тестированием работает неэффективно. Это не значит, что в CD-среде нет QA, это значит, что в CD-среде QA другой.


Единственный сценарий — тестировать на боевых серверах, чтобы исправить ошибку в следущем билде.

Это, кстати, неправда. CD позволяет ручное тестирование на соответствующей среде, столько раз, сколько нужно — просто сразу делается оговорка, что такое тестирование замедляет цикл. Компромис между одним и другим каждый выбирает для себя.


интеграционное и регрессионное тестирование плохо поддаётся автоматизации

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


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

И чем вам тут поможет "традиционный QA"? Тем, что он кликает случайным образом?


код автотестов также может содержать ошибки

… люди, которые делают тесты руками, ошибаются больше.


Но, снова повторюсь, DevOps — он не обязательно про CD (хотя обычно предполагает CD), он про то, чтобы команда разработки была прямо задействована в процессе обслуживания (начиная с развертывания) продукта.

Простите конечно, но тестировщики тестируют не как на душу ляжет, а по тест-плану с тест-кейсами. Они же этот план и создают, основываясь на требованиях, явно или неявно сформулированных. То, что они потом это делают руками или автоматизируют скриптами, не меняет качества покрытия. Если сценарием тестирования не покрывается участок с ошибкой, то он и руками не будет простестирован, потому что он не покрыт сценарием.
Ваше утверждение, что регрессионное тестирование плохо поддаётся автоматизации просто ошибочно: оно гораздо лучше в автоматизированном виде, чем в ручном, потому что у вас всегда воспроизводятся все сценарии одинаково, что для регрессии просто супер важно.
Проблема в другом, как мне кажется: DevOps — это идеология, и принятие её (как и не принятие) лежит в иррациональной области. Это как с коммунизмом: само по себе ничего страшного, но почему-то потом у некоторых идеологов оказывается, что кибернетика и генетика ему противоречат. С DevOps тоже, есть условно маоисты-devops, есть троцкисты-DevOps, а есть вообще devops-чучхе.

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

Теперь по поводу ручного тестирования, его смерти и смещения в автоматизацию.
Первое: Автоматизация заменяет регрессионное ручное тестирование.
Это как раз те самые тесты, которые точно так же идут по заранее расписанным сценариям и точно так же, как и автотесты, пропускают всё, что ими не покрыто.
Это регулярно повторяемая, однообразная и не слишком интересная работа — то, что стоит автоматизировать всегда и при любой возможности.
Это освобождает ресурсы вашего отдела тестирования для исследовательского тестирования и тестирования методом свободного поиска. Как раз тех видов тестирования, где нужны интуиция, чувство прекрасного, здравый смысл и аналитические способности. Словом, всё то, что может человек, но не может скрипт написанный человеком.

Убивает ручное тестирование вовсе не ДевОпс, а потребности бизнеса и реалии рынка.
Ручное тестирование убивает скорость.
Сейчас даже у SPA для продажи носков такое количество ручек, состояний и внешних интеграций, что тестировать его руками — долго и неэффективно.
А делать кодфриз на неделю, что бы хорошенько всё оттестить не нужно примерно никому.
В то же время инженеры по тестированию — ограниченный, дорого и плохо масштабируемый ресурс.
Автотесты, в свою очередь, масштабируются очень просто и стоят относительно недорого.

Ну и скопом отвечу на ваши комментарии выше:
1) «Традиционный QA» отлично себя чувствует в полном CI\CD окружении. Потому что тестирование — один из этапов CI\CD.
Размазывание ответственности за качество на всю команду это то, за что будет неистово топить любой адекватный QA инженер. И этот тезис появился задолго до того, как девопс практики вошли в моду.
Может ли команда, следующая devops практикам существовать без QA Engineer как выделенной роли? Да, может.
Значит ли это, что там не будет QA, QC и тестирования как набора активностей? Нет, не значит.

Кажется у человека, на которого вы ссылаетесь, просто каша в голове из понятий.

2) Интеграционное и регрессионное тестирование — отлично поддается автоматизации. Это тривиальнейшая инженерная задача, которой за месяц обучается человек, раньше не писавший код вообще.
Это полтора прикладных инструмента, три паттерна и совершенно типовые архитектурные решения.

3) Код автотестов может содержать ошибки. Это так. Точно так же, как ошибками может обладать документация для тестирования.
Но тут есть одна ключевая разница: автотесты ведут себя одинаково всегда. Вы можете бесконечно расширять их набор, увеличивая покрытие, и их поведение не будет меняться от того, что вам понадобилось прогнать регрессионный набор тестов 12 раз подряд в ночь с пятницы на субботу.
Ручное тестирование всегда обладает человеческим фактором. В случае регрессионного и функционального тестирования — это огромный минус. Потому что глаз замыливается, внимательность может падать, а прогонять нон-стопом регрессионные тесты — это своего рода пытка.

Меняется ли тестирование и QA? Да, меняется.
Происходит ли это за счет популяризации девопс практик и инструментов? Да, в том числе.
Приводит ли это к смерти тестирования? Нет, не приводит. Это приводит к тому, что в тестировании начинают использовать код там, где код эффективнее, оставляя человеку те области, где он (пока что) выигрывает.

P.S. И да, я работаю QA инженером и прекрасно вижу, что происходит на QA-рынке.
Никакой смертью QA там и не пахнет. Зато действительно появляется всё больше компаний, которые понимают, что просто посадить 10 тестировщиков что бы они нон-стопом гоняли одни и те же тесты из релиза в релиз — недостаточно для обеспечения качества продукта.
Спасибо за комментарий. Очень полезное дополение к статье и взгляд со стороны QA. К сожалению очень часто внедряют не правильный DevOps, а «DevOps», когда от него берётся то, что сокращает затраты, но не берётся то, что эти затраты повышает. Например, попытки внедрения DevOps во взрослых проектах с монолитной структурой и не покрытых тестами. Убираются «ручные» тестировщики, но не заменяются специалистами по QA-автоматизации и т.д. Т.е. если вы пишите новый проект, готовы вложиться в TDD и автоматизацию, используете микросервисы или другую модульную архитектуру, то DevOps может быть отличным выбором для вас, но если у вас легаси-проект, то DevOps с лёгкостью убъёт его.
Ещё раз. Как таковой DevOps ничего не убивает.
Любые изменения в процессах, будь то внедрение аджайла, девопс практик, или ещё чего-нибудь могут убить проект.
Я точно так же видел проекты, которые загибались под гнетом тестирования. Просто потому, что продукт требовал быстрой поставки в продакшен, простых но быстрых изменений, проверки гипотез на проде и прочего.
А регрессия на нем шла в ручную в среднем три дня.
Потом там находились баги, они правились, и регрессировали ещё три дня.
Потом всё таки выкатывались в прод, находили баг в проде, и выпускали три дня хотфикс.
На развитии продукта в такой схеме можно просто поставить крест и разойтись по домам.

В России всё плохо с QA. В принципе ОЧЕНЬ плохо.
Компаний, которые у себя внутри держат не специалистов по тестированию, а QA инженеров — предельно мало (в Питере, например, их можно по пальцам посчитать).
И естественно, внедрение ДевОпс практик в команде, где единственным гарантом хоть какой-то работоспособности приложения является то, что N человек X часов гонят тесты — не приведет ни к чему хорошему.
Не потому, что ДевОпс это плохо. А потому, что ДевОпс призван ускорять деливеринг. А в таких условиях ускорять его нереально.

Точно так же внедрение аджайла в компании, где никто ничего не может без четко расписанного ТЗ и микроменеджмента — убьет всё нафиг. Но это не значит, что аджайл — это зло.

Просто любая методология, практика разработки или инструмент требует определенных условий, для её использования.
Но всегда есть карго культ, когда люди тупо копируют практики у успешных товарищей по отрасли и думают, что это решит все их проблемы.
Но это не изъян практик, это изъян людей.
Три дня на регрессию — это очень неплохо. В Канаде сталкивался с ситуациями когда регрессионное тестирование занимало недели и все ресурсы команды.

А так — да, девопс не убивает — убивают карго-культы.
Всё сильно зависит от специфики.
Если вы выпускаете картриджи для нинтендо, то 3 дня фриза и тестирования — отличный результат. Потому что риски высокие, откатиться просто так нельзя, багфиксы не выкатишь и вот это всё.

3 дня регрессии для продукта, в котором обновление которого у всех клиентов занимает 10 минут — неприлично много.
Веб, клиент-серверные приложения десктоп-приложения, вот это всё. Вы можете выкатывать и откатывать фиксы, управлять версионностью, мониторить качество продукта и пользовательский опыт.
Нон стопом, быстро и безболезненно. Вам выгоднее и пользователям выгоднее получить полезную нагрузку ASAP, пусть даже сначала она станет полезной для 80% пользователей, потом для 90, потом для всех.

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

Разработка ускоряется, никто не готов работать по вотерфоллу где каждый этап водопада занимает месяц. Это не выгодно, не эффективно и не нужно ни разработчикам, ни заказчикам, ни пользователям.
Есть отдельные категории продуктов, где цена ошибки слишком высока, что бы от этого можно было полностью уйти, но таких продуктов — реальный минимум.
3 дня регрессии для продукта, в котором обновление которого у всех клиентов занимает 10 минут — неприлично много.


Нет, это не много. Частота релизов не предполагает качественный продукт, а предполагает только возможность быстро исправить косяки. Но это можно и хотфиксами сделать. Я считаю, что частота релизов должна быть не чаще чем в 1-3 месяца. В крайнем случае — 2 недели (длина спринта в скраме). Можно и 2 раза в день релизиться, но зачем. Если вы добавляете важный функционал, то его разработка и тестирование займёт недели (если хотите качественно сделать), а двигать кнопочки и добавлять свистелки, так чтобы интерфейс пользователя менялся каждый день — это даже вредно (и пользователям даром не нужно). Тогда уже нужно разделить релизы на 2 вида: Major выходит раз в несколько недель-месяцев и содержит более глобальные изменения и новый функционал. Такие релизы должны быть хорошо протестированы (в том числе и вручную). Minor-релизы могут выходить с частотой от дня до недели. Допускается только исправление существующих багов и добавление «срочного» функционала. Данные релизы тестируются на регрессию автотестами, плюс в ручную тестируется затронутый функционал…
Я считаю, что частота релизов должна быть не чаще чем в 1-3 месяца.

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

1-3 месяца — это из моего опыта для коробочного продукта или большого enterprise приложения. Если у вас один заказчик которому нужно «вчера» или если вы пишете внутренний проект, то релизиться можно и чаще. Вообще правило должно быть такое: чем критичнее функционал, тем реже, но качественней должны быть релизы.

… а если в приложении есть менее и более критичная функциональность, что делать с релизами приложения? А если у вас SaaS, на котором крутится enterprise, он куда попадает?

«Правильный» Enterprise никогда не будет рад частым релизам, т.к. в больших компаниях много времени уходит на согласование и Change-менеджемент. Если для релиза вам нужно собрать 100500 бумажек и получить согласования от внутренней безопасности, админов и т.д. То вы не сможете релизиться раз в 3 дня. А ещё ведь нужно до пользователей донести изменения… Добавьте к этому, что чаще всего у компании есть только 1 или 2 ночи в месяц, когда можно делать изменения.

Если в приложении есть более и менее критичная фукциональность, то фичи затрагивающие критическую часть обновляются только в Major релизах, а некритическая может быть обновлена хотфиксами.

У нас с вами разное понимание "правильного" энтерпрайза. В моем понимании, правильный энтерпрайз как раз был бы рад частым релизам, потому что быстрые изменения — это конкурентное преимущество, но весь описанный вами ад им мешает.


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

В девопсе админы сидят в команде, какие согласования?


а некритическая может быть обновлена хотфиксами.

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

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

Мне кажется, что для любой компании приоритеты будут следующие:
1. Стабильность существующих процессов и систем
2. Безопасность
3. Новые фичи (пусть и полезные для бизнеса)

Т.е. если погоня за скоростью внедрения новых фич приводит к проблемам в стабильности или безопасности, то зачем эти фичи вообще нужны?! Я не призываю релизиться раз в квартал или раз в год. Но релизиться нужно тогда, когда все автотесты зелёные, весь новый функционал протестирован и проверены связанные фичи. Если вы можете это сделать за день/неделю, то ничего страшного в релизе каждую неделю не будет. Если же вы «забиваете» на тестирование из-за того, что баг можно будет быстро подправить в следующем билде, то вы создаёте себе проблемы. Потому что баги могут приводить к потере целостности данных или потере самих данных, а также приводить к утечкам данных из-за сломанной безопасности…
В одной крупной международной нефтянной компании именно такие процессы, и они обоснованны тем, что любой простой из-за проблем с ПО и сетевой инфраструктурой стоит сотни тысяч долларов.

… вы забыли добавить "и не нашли способа работать без простоев".


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

Забавно, простой стоит сотни тысяч долларов, а отсутствие фичи — нет? Но тогда и простой этой фичи впоследствии не должен стоит ста тысяч долларов, правда же?


Мне кажется, что для любой компании приоритеты будут следующие:

Если вкратце, то вам кажется. Не для любой.


Т.е. если погоня за скоростью внедрения новых фич приводит к проблемам в стабильности или безопасности, то зачем эти фичи вообще нужны?

А если не приводит? Вообще-то, и CD, и DevOps — это про повышение предсказуемости релизов, а не наоборот.


Я не призываю релизиться раз в квартал или раз в год.

То-то вы выше писали "Я считаю, что частота релизов должна быть не чаще чем в 1-3 месяца".


Если вы можете это сделать за день/неделю, то ничего страшного в релизе каждую неделю не будет.

Вот некоторые методики — они как раз про то, чтобы делать это быстро.

Зачем держать в незарелиженном состоянии фичу, которая уже полностью готова, протестирована и т. п.? Особенно, если предполагается, что её релиз будет приносить деньги или сократит потери денег?

Согласен. Тогда сказанное мной выше можно подкорректировать — Major релизы выпускаются по мере готовности нового функционала и важных изменений. Они требуют ручного тестирования в том числе. (Т.е. если фича готова, то релизим её)
(Я разработчик с 10-и летним стажем [..] Уверен, что многие не поддержат мою точку зрения и могут назвать эту статью «плачем динозвара»,


Рановато (лет на 20 точно как) вы на себя лычку «динозавра» примеряете.

Сейчас Agile превращается в DevOps.


Шта???
Сейчас Agile превращается в DevOps


Я про карго-культ. Раньше на каждом шагу кричали, что «у нас Agile», теперь кричат «мы DevOps». Хотя ни о первом, ни о втором не имеют чёткого представления, а пытаются внедрить следуя тренду, а не необходимости…
Я для себя я определяю DevOps как «логистика в сфере разработки ПО». Чтобы нужные артефакты попали в нужное место в нужное время. И произросло оно из необходимости централизировать и специализировать эту область деятельности. Грубо говоря, десять лет назад можно было обойтись скриптиком на локальной машине, при сегодняшних масштабах разработки, аутсорсом и пр. это жизненная необходимость которую я не могу поставить под вопрос.
Для примера:
У нас чтобы разработчик увидел свой код в сборке (в продукте) может пройти два дня. Потому что некоторые слои программы собираются отдельно и, если между ними есть зависимости, их нельзя интегрировать одновременно.
В проекте задействовано порядка 200 разработчиков, представляете эффект от улучшения логистики?

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

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

Ну и программисты тоже народ порой своеобразный:
8. Многие из вас знакомы с достоинствами программиста. Их всего три, и разумеется это: лень, нетерпеливость и гордыня.
— Larry Wall
Из "50 цитат о программировании всех времён"

Да, некоторым хочется сказать — «не умничай, а просто делай».
У нас приложение состоит из слоев, и часто так получается, что все таски по фиче закрыты, а фича работает наполовину. Но каждый свою часть работы посчитал законченной, потому что «ну если у них там не готово то это не мои проблемы».Получается как у Райкина: «Кто сшил костюм?» Даже мне приходится так делать (моя задача автоматизация приемочных тестов — на что смог написать автоматизацию на то и написал, не вечно же ждать пока все готово будет). А общая проблема в неадекватных требованиях заказчика. A фирма соглашается на условия заказчика потому что жить на что-то надо. А заказчик за что платит, то и имеет. Если заказчик десять раз в год меняет свои хотелки — так будет выглядеть и код и конечный продукт. Как франкенштейн. Потом заказчик понимает, что время экспериментов подошло к концу и бюджет тоже — пора на рынок, просят одеть франкенштейна во что нибудь яркое и красивое. Вот вам новый Skype.

Вообще по современным тенденциям хочу сказать:
Когда твой компас — страх за собственную задницу — ты точно будешь двигаться не в том направлении.
Когда твой компас — жажда денежной выгоды — ты будешь двигаться не в том направлении.
Но если твой компас — это пользователь, которого ты хочешь сделать немного счастливее, ты придешь к своему пользователю.
— © Я

> Но если твой компас — это пользователь, которого ты хочешь сделать немного счастливее, ты придешь к своему пользователю.

Станешь ли ты при этом счастливее сам, вопрос остаётся открытым.
Мне кажется, только когда ты приносишь радость другим ты становишься счастливее сам.
Дело в том, что разработчики, как правило никак не участвуют в создании идеи продукта. Они только исполняют необходимую для воплощения чьих-то замыслов работу. Именно поэтому люди уходят в стартапы.
Надо видеть свой вклад в продукт. У нас как-то делали опрос, типа, насколько вы идентифицируете себя с продуктом который делаете, и показатель по этому параметру был очень низкий. Я вот только не помню по всей фирме или это специфика нашего проекта. Наддо будет спросить в отделе.
Я вот, нахожу баги, работа такая, и радуюсь, чем выше приоритет бага тем больше я радуюсь — а тимлид с точностью наоборот. Он умом понимает, что это важная работа, но радоваться багам не умеет.

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

Когда твой компас...


Этак можно договориться до пафосного:
Если твой компас — это пользователь, которого ты хочешь сделать немного счастливее, ты придешь к своему пользователю.
Когда твой компас — страх за собственную задницу — ты придешь к своей заднице.

На самом деле ни то, ни другое. Видел людей, думающих, что делают других счастливее («стоять, я сейчас вас научу радоваться и смеяться!»), но людям от этого было неудобно и нехорошо.
Видел людей, заработавших свою копейку-другую, и успокоившихся — и хорошо стало как раз юзерам.
Тут все от компании зависит. Видел(работал) там где DevOps'ы не как не конфликтовали ни с QA ни с разрабами и все работало как часы. Выделены роли были четко. Разница между DevOps и классическим админом было в том, что он(DevOps) мог запросто посмотреть в код существующего проекта и разбить его скажем на 2 микросервиса(не обязательно своими руками, но он понимал в чем соль самого web приложения), все запаковать в контейнер и пустить в продакшн.
И видел(работал) когда все роли смешивались в одну (ты как разраб и за качество и за деплой отвечаешь), стоит ли говорить что во втором случае качество было ниже плинтуса, вечно винили во всем разрабов. А если сидишь пол дня тестишь на всех платформах фичу, то тоже претензии. (Сбежал из второй конторы очень быстро)

Side note: сколько столкнулось в комментах мировоззрений!

DevOps — лигр админа и девелопера. QA здесь причём? Основная цель QA — качество. И если QA-шнику нужна инфраструктура, то он её с девопса и спросит. Те же автотесты (не-юнит) пишутся всё равно QA-шниками. Не понял посыла статьи.

На мой взгляд, корень проблемы в том, что DevOps — это на сегодняшний день buzzword, который каждый понимает по-своему. По-моему, правильный DevOps это когда на проекте есть аналитики, тестировщики, несколько групп разработчиков, админы, сетевики и есть группа специалистов умеющая, всё то, что умеют специалисты вышеперечисленных групп. Пусть даже поверхностно, главное — чтобы понимали процессы в каждой группе.
Меня забавляет другое. В целом, если утрировать, то DevOps — это админ + девелопер. Если говорить про это именно как про методику, то это взаимодействие админов и разработчиков.

Это я к чему. Так было, на моей памяти всегда, все работали сообща. Но N-ное количество назад появилось это надоедливое слово DevOps и отчего такое внимание привлекло. Не понимаю.
Так было, на моей памяти всегда, все работали сообща.

То есть вы никогда не встречались с "ну, мы написали, теперь вы сами ставьте и управляйте"? Счастливый человек.

Такое я наблюдал всегда по отношению к тестировщикам со стороны разработчиков. Мол, «мы написали, проверяйте сами».

Вот с operations все то же самое. Разработчиков, которые думают, как их детище будет обслуживаться, сильно меньше, чем хотелось бы.

Ну, для начала стоит заметить, что никто особо не представляет, что такое этот DevOps. В общем случае это представляется как слом стены перекидывания ответственности между Dev, Ops, и, внезапно, QA и Sec командами, если они есть.


То, что многие относят к повышению доставки все-таки на мой взгляд не DevOps, а именно CI/CD практики.


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


В общем случае это означает что разработчик, когда пишет код должен немного думать о том, как его будет удобно протестировать, деплоить и мониторить. Ops должен в свою очередь предоставлять и разрабатывать инфраструктуру под приложение, для чего должен понимать как оно работать и что ему нужно, а QA должен приблизительно понимать как это все работает и что где можно потыкать. И как не удивительно, это все направленно на повышение качества.


С другой стороны современное ПО просто настолько сложное и засыпанное абстракциями по всем местам, а опытных программистов, которые еще могут работать с современными технологиями, а не только php 4/python2.3/вставь старую технологию становится все меньше, то и получаем дефицит квалифицированных кадров и как следствие плохое качество в ПО.

UFO just landed and posted this here
UFO just landed and posted this here

Нет, нет, нет.


Agile, DevOps — это естественное развитие процессов разработки, уменьшающее время между появлением требования и выкатыванием его в продакшн.


Давайте и я дам свое определение как практик. DevOps — это набор практик автоматизации типичных задач администрирования с целью максимального ускорения их выполнения и минимизации ошибок.

Автоматизация типичных задач администрирования лишь один из способов решения основной задачи DevOps: сделать разработку, поставку и эксплуатацию если не одним процессом, то очень согласованными процессами. И всё это с целью ускорения доставки фич и багфиксов до пользователей.


С точки зрения DevOps особо без разницы автоматизирован процесс билда и деплоя или нет, если между разработчиками, релиз-инженерами и админами нет чёткого понимания, что каждая из сторон ждёт друг от друга и готова дать друг другу. Автоматизация — это уже оптимизация процессов, но сначала их нужно построить.

Отличная статья и отличные мысли, на которые я раньше не обращал внимание. Однако, давайте теперь повангуем.
Из статьи отчетливо видно, что в DevOps оставили ответственность перед Dev и перед Ops, а остальных (аналитика, архитектора, тестировщика) выкинули на обочину современности. Причем, чем выше скорость разработки, тем меньше они участвуют — это ответ всем тем, кто выше заявляет, что у них не так. У вас, парни, просто медленный проект. Архитекторами всегда топят печку паровоза, чтобы высрать технический долг из выхлопной трубы.

Итак, те, кто захочет повышать качество продукта, приклеют обратно аналитика к DevOps. Не силен в сокращениях, поэтому назовем это AnalDevOps. Потом вернут архитектора. AnalArchDevOps. Потом тестировщикам дадут время сделать работу качественно — AnalArchDevQAOps.
Короче, они вернутся в то, что было до DevOps, сохранив многие аспекты этого DevOps, типа унификации сред и атомарно-модульной структуры приложения.
При этом сама этимология слова DevOps уйдет.

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

Поэтому все разговоры про низкое качество DevOps, конечно, справедливы. Однако, релевантны ли?
Из статьи отчетливо видно, что в DevOps оставили ответственность перед Dev и перед Ops, а остальных (аналитика, архитектора, тестировщика) выкинули на обочину современности.

Важное уточнение: из статьи отчетливо видно, что в DevOps, как его понимают в статье, оставили [...] выкинули [...].

UFO just landed and posted this here
> взять к примеру последнюю версию Skype, хотя примеров намного больше

Скайп и подобные вещи просто пошли путем удешевления переходом на веб-технологии. Т.е. не думаю, что девопсы тут виноваты.
Проблема DevOps в разработчиках. Они не способны качественно проанализировать требования и протестировать результат, т.к. они смотрят на продукт через призму кода, а не с точки зрения пользователей.

Нифигасе заявление! Да практически все идеи генерятся девелоперами! Просто в большинстве компаний сложилась такая номенклатурная организация, что между пользователем и девелопером стоят люди, называющие себя аналитиками, которые практически никогда в жизни не писали код. Они слабо представляют сам процесс разработки, архитектуры и огранизации системы, возможности кода и трудозатраты, и тем не менее сидят на своем месте и получают зарплаты. Это такие как Tom Smykovski из легендарного Office Space, который заявлял: "I have people skills":
image


Нам нужно сохранить роли аналитиков, тестировщиков и внедрения в команде. Разделение труда ведёт к повышению качества и производительности (вспомните Стаханова и его идею разделения труда в шахте)

Вы упускаете ОЧЕНЬ важный момент: разделение труда работает только в тех системах, где взаимодействие между членами минимально, и упрощено насколько это возможно, а сам труд реально разделяем — тогда это работает. Инженерная же идея, тем более достаточно сложная, очень плохо скалируется по головам. Если команда девелоперов придумала и закодила функционал, нужно будет объяснять все детали реализации команде тестировщиков, чтобы те, из того, что они поняли, смогли написать кое-какие тесты. А кто лучше сможет написать тесты и покрыть больше кейсов, чем сами девелоперы?


Из негативных эффектов разделения труда — это круговая порука и сбагривание ответственности. В девопсе же девелопер несет ответственность до конца.


P.S. Говоря о девопсе, вы полностью упустили сам "опс", например команду админов, которая файерволом стоит между девелоперами и продакшном и фактически не дает девелоперам видеть, что происходит с их кодом на сервере.

Если команда девелоперов придумала и закодила функционал, нужно будет объяснять все детали реализации команде тестировщиков, чтобы те, из того, что они поняли, смогли написать кое-какие тесты.

А зачем объяснять тестировщикам детали реализации, если тестировать надо ожидаемое поведение в первую очередь?

Прошла первая очередь, тесты отработали, и все выкатили на продакшн — и все свалилось в первый же день. Причина — какой-нибудь resource или memory leaking в пулах или кешах. Девелоперы винят тестеров, что те не обнаружили. Тестеры отмазываются, что это нефункциональные требования и ничего не хотят об этом знать. Вот если бы девелоперы сами готовили тесты, то метрики пулов скорей всего были бы включены в тесткейс.

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

С какой радости? Девелоперы точно так же любят отмазываться про нефункциональные требования.

Когда ответственность за функционирование и сопровождение системы ложится полностью на девелоперов, отмазаться будет сложно: ваша система периодически падает — чините как хотите, тестируйте, мониторьте — ваши проблемы.
С другого конца, когда требования устанавливает некий дядя, называющий себя product owner-ом, девелопер никогда не видит реальных результатов своей работы, не получает должного feedback (кроме бесконечных ошибок и изменений), то его не особо беспокоит качество кода, нефункциональные требования и пр. — пусть об этом голова болит у дяди, ему за это платят. Цель девелопера в этом случае становится не сделать продукт, а закрыть issue.
Так что чем больше посредников в процессе разработки, тем больше разделение ответственности, что всегда негативно сказывается на качестве финального продукта.

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

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


Так что чем больше посредников в процессе разработки, тем больше разделение ответственности, что всегда негативно сказывается на качестве финального продукта.

На чем основано это "всегда"? В моем опыте это не так.

DevOps — это один из видов внедрения и разработки слитый воедино. Вытесняет традиционных разработчиков, администраторов, тестировщиков. Их роль становится крайне неочевидной и на них начинают резко экономить. А еще практика показывает, что программисты не умеют писать документацию доступную для пользователя. Они мыслят по другому. Они по другому видят свои приложения. Эта практика может быть применена только когда потребитель продукта готов сам стать разработчиком и начать ковыряться в качестве продукта. Без погружения в продукт всех заинтересованных лиц достигнуть качественного результата невозможно. Автоматизация некоторых из процессов дает лишь частичную разгрузку лиц не участвующих в разработке, но и приносит новые уязвимости и больше отстраняет их от продукта.
Я работаю сейчас в такой команде. На деле все выродилось у нас в то, что все занимаются, чем хотят, и скорость разработки сильно упала. Все пытаются пилить код, из-за этого качество кода тоже падает. Лоскутное одеяло, костыли и тд, потому что у всех равное право голоса («мы же все равны и все разработчики»). Короче, идея хорошая была, но на практике восторгов не вызывает.
правда заключается в том, что толк в разработке есть только от тыжпрограммиста.
Все остальные просто не справляются. Особенно аналитики.
А чем измерять толк? Количеством строк кода? Тестеры нужны, причем два уровня:
— те, кто знают, как должно работать и проверяют соответствие реализации поставленной задаче, поиску технических несоответствий
— те, кто ничего не знают, а выполняют роль простых юзеров, и пытаются убить/сломать/испортить реализацию, как «обезьяны с гранатами»
По мне, так девопс нужен, только должен быть не просто «натасканный системщик», а скорее архитектор со знанием инструментария аналитики и работы программиста (уметь кодить хотя бы на уровне немного выше среднего)… В противном случае — это тот же самый менеджер продукта, которому понавешали обязанностей, которые он не знает как выполнять, потому выполняет «как умеет», пока не научится выполнять «хоть немного»…
Давайте предположим, что вы пишете какой-то embedded продукт проектом в 50 разработчиков и 30 тестировщиков.

Допустим продукт средней сложности, ваша операционка + ПО компилируется около 5 часов на рабочей машине.
В день по 100 коммитов. В год по 4 релиза + срочные исправления.

Чтобы прогнать хотя бы regression тесты, нужно иметь пару десятков устройств, автоматизацию билда-заливки на устройство — запуск автотестов, и какой-то оптимизатор компиляции (кеширование неизмененных бинарников. возможно небольшая ферма с распарралеливанием компиляции, чтобы сократить 5 часов до получаса или меньше).

Кто будет все это дело организовывать, настраивать, перенастраивать в случае модернизации? Программист?

Configuration engineer не такая частая вакансия, так как на проект, который имеет приличную собственную инфраструктуру обычно нужны 1-3 человека, причем масштабирование не всегда нужно (количество сотрудников может вырасти в два раза, а девопсов может остаться столько же).

Часто configuration engineer совмещает в себе и devops и release manager
И например не позволяет девелоперам лезть в продакшен и выкладывать пофикшеный на коленке бинарник руками, если есть заранее согласованная схема, с регрешн тестами.
Например если инфраструктура это не один-два жалких сервера с git/jenkins/apache, а пару десятков машин с разным назначением, то это достаточно объемным кусок работы, который и не входит в круг обязанностей программиста/архитектора/аналитика.

Это задача configuration engineer, который в силу своей работы часто должен обладать навыками системного администрирования. Но при этом не всегда уметь пересобрать gentoo, но это и НЕ НУЖНО.
Либо Вы ошиблись ссылкой «ответить», либо плохо читаете… Вообще-то я не против такой сущности как ДевОпс, но этот человек должен обладать набором знаний, а не быть простым системщиком или менеджером, как это ооочень часто происходит.
Программист не должен заморачиваться вообще процессами сборки продакшна, передачей его на тестирование или самим тестингом и уж тем более деплоем на рабочие площадки.
Так что не совсем понятно, почему Вы МНЕ адресовали Ваше сообщение =)
Программист не должен заморачиваться вообще процессами сборки продакшна, передачей его на тестирование или самим тестингом и уж тем более деплоем на рабочие площадки.

В DevOps (как методологии) как раз должен.

Ну скажем так, лично я не следую всем методологиям и критериям «буква в букву» ;)
ИМХО — понятие ДевОпс-а нужно, но только в таком виде, в котором не подразумевается размытости должностных обязанностей и ответственности, и уж тем более перераспределение функций, которые на людей, которые НЕ ДОЛЖНЫ ими заниматься…
Проект = архитектор/проектировщик, код = программисты, тест = тестировщики, деплой = менеджер/администратор, взаимодействие с юзерами = саппорт…

Ну или я допускаю, что не совсем понимаю именно методологии =)
понятие ДевОпс-а нужно, но только в таком виде, в котором не подразумевается размытости должностных обязанностей и ответственности, и уж тем более перераспределение функций, которые на людей, которые НЕ ДОЛЖНЫ ими заниматься…

И какой же это вид?

«деплой = менеджер/администратор»
Менеджер проекта — это обычно человек, от которого зависит жизнь проекта. И в первую очередь это его навыки организации/коммуникации.

Его задачи:
— убедить заказчика, что именно ваша команда справится лучше, быстрее и дешевле других. При этом выбить достаточный бюджет на проект.
— Подобрать людей в команду и следить за командной работой
— Организовать работу команды (разработать распорядок и правила работы, организовать работу команды таким образом, чтобы люди не перегорали, чтобы было достаточно и сеньоров, на которых держится проект и мидеров, которые делают кучу работы, и джуниоров, на которых зарабатывают), при этом чтобы текучка была без риска для проекта.
— Организовать финансирование как людей так и оборудования, искать возможности расширить и улучшить бизнес, выбить новые рабочие места (вы пишете продукт, а индусы тестируют — убедить что вы сможете протестировать лучше) и так далее.
— Регулярное общение с заказчиком, слежение за настроением. Для этого нужна и красивая отчетность и поиск возможностей, и слежение за политической обстановкой в компании заказчика.

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

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

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

Программист должен иметь общее представление сборке продакшена и передаче на тестирование, чтобы SDLC вообще работал и чтобы можно было выработать оптимальный путь.
Программист должен иметь общее представление о тестировании, ибо он пишет юнит тесты, и он получает репорты от QA (должен понимать хотя бы в общих чертах как они тестируют). А в случае автоматизации тестирования, вполне может быть что будет непосредственно принимать участие в оптимизации процесса. Нередко в код необходимо писать так, чтобы тестирование продукта легко автоматизировалось. Вплоть до целого API для этого дела.
Деплой на рабочие площадки — рядовая задача. Если программист не умеет развернуть собственный продукт — как он вообще программирует. Другое дело, что он не должен ковырять и настраивать инфраструктуру проекта.
оу-оу-оу… не ожидал такого напора от содружества =))) попробую изложить свое видение этой единицы процесса и причины… (эти выводы у меня сложились непосредствено на личном опыте работы в команде без/с девопс-ом — и негативные и позитивные)…
1. да, именно админ/менеджер — т.к. он как раз в первую очередь обладает умением коммуникации и умением разобраться и настроить, и не надо путать с «менеджером-продажником» (задача которого убедить, что мы такие клевые)
2. навыки программирования ему как раз и нужны для того, чтобы он знал и умел настроить автоматизированные системы деплоя, тестирования подключить нужные библиотеки и т.д.
3. навыки тестирования нужны, чтобы вместо отвлекания девелоперов на исправление какой-то мелочи в тестах, мог это сделать сам, особенно сли речь идет именно об изменении параметров конкретного теста
4. да, именно конкретный человек должен отвечать за попадание продукта в продакшн, а не девелоперы, которых может быть десяток-два-пять… девопс получил результаты тестов, принял решение устраивает ли продукт, выполнил деплой на прод или отправил на исправления, а не девелопер Вася, получив по своей части «добро» прощелкал, что зацепил нечаяно кусок работы девелопера Гены…

Да, такой человек будет стоить реально денег, может я частично даже его путаю с СЕО проекта, но имхо — это правильнее, и когда мы начали работать именно так, результаты стали существенно лучше (хотя наш девопс начинал именно с позиции просто админ, а в процессе уже обучался и часть функций взял на себя, а мы ему поначалу помогали кто чем мог)…

Принимать решение о деплое/релизе девопс или не должен вообще, или только в рамках частей за которые он отвечает, например видит в логах билда варнинги и принимает решение пускать билд с ними на деплой или нет. Анализ результатов тестирования в общем случае в его обязанности не входит: "визирует" на качество и окончательное решение принимает или глава/представитель QA, или ПМ.

девопс получил результаты тестов, принял решение устраивает ли продукт,@

Решение, устраивает ли продукт принимает заказчик, либо менеджер проекта если это свой продукт. А не девопс.

Вы реально не понимаете, что devops — это больше техническая должность, а не менеджерская?

а не девелопер Вася, получив по своей части «добро» прощелкал, что зацепил нечаяно кусок работы девелопера Гены…

За эти проблемы отвечает кроссчек, который проводится архитектором проекта (с большим опытом разработки), а не девопсом (с некими навыками).

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

Лезть в епархию QA со своими коммитами?

Вы описываете уже даже не full stack разработчика, а какого-то full-stack-клиента-исполнителя-маркетолога-менеджера.
Вы реально не понимаете, что devops — это больше техническая должность, а не менеджерская?


А Вы реально читаете только то, что хотите? Напоминаю…

По мне, так девопс нужен, только должен быть не просто «натасканный системщик», а скорее архитектор со знанием инструментария аналитики и работы программиста (уметь кодить хотя бы на уровне немного выше среднего)…
а скорее архитектор со знанием инструментария аналитики и работы программиста (уметь кодить хотя бы на уровне немного выше среднего)…


Хм, в моем понимании, архитектор не может быть ниже senior. Как посредственный разработчик может строить архитектуру проекта?

Объясните, как частота релизов связана с качеством?


MS DOS, например, имел много лет одну стабильную версию. Volkov Commander работает до сих пор, уже 20+ лет. Скуйп, обновляется чуть ли не раз в неделю, но лучше, мягко говоря, не становится, более похоже, что заплатка на костыле. Чем реже релиз, тем лучше продукт!

И как с помощью VC скопировать файл с длинным именем, не потеряв его?
(Не очень уверен что и файл >2гигабайт можно скопировать).
Про версии MS-DOS, который выходили от раз в несколько лет до нескольких раз в год (или их автоматом считаем нестабильными?) не будем.

Дос 6.22 до сих пор стабилен.
А vc отлично работает, если его применять для того, для чего он разработан. Как и doom, например.

Volkov Commander работает до сих пор

Но ведь это неправда. Сегодня дос 6.22 практически никто не использует (ну может какое-то там нью-йоркское метро.

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

Что именно неправда?
Работает до сих пор означает работает до сих пор. И ведь работает.

Если для работы нужны специальные условия — значит не работает.
Даже под Win-7 он не запускается, а она уже устаревает.

С таким же успехом я могу сказать, что keyrus работает.
Или что NC который для ДВК работает (только сомневаюсь что вы сможете легко найти виртуализацию, чтобы его под rt11sj запустить).
Неее. Операционка в Nokia 3310 работает до сих пор? На вояджере работает?
И все это без ежедневной скачки, стендапов и прочего бреда

Обычно для любых программ нужны особые условия, хотя бы ОС будь то Windows 10 или PC DOS 3.3. "Write once, run anywhere" или как там было, в реальности нет. Современность окружения тоже условный критерий: есть подозрение, что тот же VC будет стабильно работать на FreeDOS 1.2 (2016 год).

Скул(какой бы не имелся в виду) тоже работает. Разница строго обратна — у него обновления выходят для соответствия современности, а DOS нефункционален, потому как «для чего он был разработан» неактуально.
Sign up to leave a comment.

Articles