Ускорение Time to Market: Опыт «М.Видео»

Александр Садыков, заместитель руководителя отдела тестирования «Инфосистемы Джет»

В прошлый раз мы рассказывали о том, какие преимущества дает ускорение Time to Market и какие финансовые потери несут компании из-за архаичных процессов разработки. Сегодня мне хотелось бы подробнее раскрыть наш практический подход к оптимизации процессов, а также поделиться опытом одного из крупнейших российских ритейлеров – компании «М.Видео – Эльдорадо».

Три года назад наша команда совместно с «М.Видео» начала внедрять подход непрерывной интеграции в процесс разработки у ритейлера, и сегодня мы продолжаем его развивать. Он не ограничивается только применением современных технологий DevOps и автоматизации тестирования. Это скорее комплексное решение по систематизации всех процессов в разработке и изменению отношения к ним вовлеченных сотрудников.

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

Ускорение Time to Market помогает компании быстрее выпускать обновления и экономить на фонде оплаты труда (ФОТ). Например, простая автоматизация сборки и регрессионного тестирования может сократить смету проекта до 10%, а если вы решите автоматизировать подготовку тестовых данных, дополнительная экономия может достигать 12%. Но это еще не все. Критически важные изменения необходимо выпускать вовремя. Это необходимо для того, чтобы быть первыми на рынке с новыми идеями, быстрее других предлагать инновационные сервисы и, конечно же, максимально оперативно исправлять ошибки.

На практике ускорение Time to Market происходит за счет полной автоматизации процессов внутри компании. Я бы выделил четыре необходимых элемента, которые помогают нам ускорить Time to Market для клиентов:

«М.Видео» – крупный федеральный ритейлер с более чем 60 различными информационными системами: от решения для управления складом или цепочками поставок до ERP и корпоративной CRM. На примере интернет-магазина мы расскажем, как компания трансформировала разработку и тестирование нового функционала.

Что же сделали в «М.Видео» с разработкой? При участии внешних экспертов в компании была внедрена совершенно иная практика сборки релизов, регрессионного тестирования и выпуска обновлений. Так, например, разработка перешла со Scrum, то есть спринтовой модели, на Kanban, когда проверка на совместимость происходит по мере готовности каждого мелкого изменения (мердж по готовности) и никому не надо никого ждать. Благодаря этому удалось сократить процесс регрессионного тестирования на три дня.

Кроме этого были автоматизированы процессы тестирования – создано более 900 сценариев, по которым происходит проверка функциональности сайта после публикации каждого обновления. Благодаря приоритизации тестов команде удалось полностью исключить наличие в релизах блокирующих ошибок, которые мешают работе сайта, и критически важных ошибок (таких, как сбои в работе фильтров товаров), а также обеспечить автоматическую проверку корректности отображения всех элементов веб-страниц.

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

Разбивка функционала на блоки и постоянная проверка взаимосвязей между компонентами также дали свой эффект. Стало понятно, на каких наиболее проблемных блоках нужно сосредотачиваться и чему следует уделять особое внимание в условиях нехватки времени.

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

Опыт показывает, что невозможно сразу «стать ИТ-компанией», а сокращение Time to Market нужно реализовывать постепенно на каждом отдельно взятом участке. Если начать с самых «болезненных» процессов, а также четко расставить приоритеты, оценить сроки и риски, составить план реализации и привлечь экспертов, можно достичь впечатляющих результатов в короткие сроки.

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

На подобных проектах внедряются методологии ускорения разработки, в числе которых QA, CI/CD и DevOps. Они все ведут к сокращению затрат, но приводят к изменениям в работе специалистов. Поэтому для каждого сотрудника нужно предусмотреть свою мотивацию, которая будет стимулировать его работать в новых условиях лучше, а не саботировать внедрение новых подходов.

Есть еще один момент. Иногда компании просто не хватает специалистов, чтобы решить какую-то срочную задачу или исправить внезапно появившуюся ошибку – нужна почти мгновенная возможность быстро расшириться, а затем сократить команду. Понятно, что в таких условиях держать штат без работы никому не интересно. Например, никто не будет держать в штате дорогостоящего специалиста по Erlang, ModBus или Clojure. Гораздо удобнее привлечь такого эксперта из компании-партнера. А для этого необходимо выстроить полноценное сотрудничество и даже интегрировать команды разработчиков, обеспечив постоянный обмен опытом.

Чтобы читатель не подумал, что мы здесь шутки шутим, приведу в пример небольшое демо, записанное одним из DevOps-архитекторов нашей команды.

На видео происходит автоматическое тестирование нашего собственного продукта. Производится запуск UI и API автотестов в системе CI/CD Jenkins.

В консоли отображаются докер-контейнеры, которые стартуют внутри тестовой инфраструктуры.

В Web-интерфейсе Jenkins можно наблюдать логи сборки тестового проекта. С помощью Selenoid UI виден ход выполнения UI-тестов прямо в браузере с помощью технологии VNC. По результатам прогона UI и API-тестов формируется Allure-отчет, и экспортируются результаты прогона в тест-менеджмент систему TestRail.

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

Повышение прозрачности работы новых направлений, а также прибыльности онлайн-бизнеса часто скрывается в оптимизации типовых узких мест, таких, например, как распространенная проблема объединения веток кода в релизную в последний день перед началом приемочного тестирования (это и было одним из краеугольных камней успеха оптимизаций в интернет-магазине «М.Видео»). Автоматизация проблемных процедур приводит к снижению количества ошибок и уменьшению трудозатрат. А аудит процессов разработки позволяет найти те этапы, на которых вы теряете больше всего времени и денег, и начать модернизацию именно с этих участков.

Первые 2-3 месяца вы не увидите радикального снижения расходов, потому что вам придется одновременно и поддерживать старый процесс внесения изменений, и внедрять новый. Сначала затраты будут даже расти, но за счет автоматизации самых неэффективных процессов через полгода обычно происходит окупаемость инвестиций – ускоренный Time to Market начнет приносить прибыль.

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