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

Привет, Хабр, меня зовут Савичев Игорь, я возглавляю направление фронтенд-разработки в Самолет Тех, а мой коллега Тимур Шахбанов — DevOps инженер. Мы занимаемся цифровизацией строительства на российском рынке, развивая IT-технологии в самых разных направлениях: от девелопмента до финтеха. Наша цель — сделать работу на стройке проще и удобнее, чтобы каждый мог внести свой вклад в создание проекта.

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

• Ускорить процесс разработки и тестирования;

• Улучшить качество кода;

• Снизить количество ошибок в продакшене;

• Облегчить коммуникацию между разработчиками и другими участниками проекта.

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

Содержание

• Что такое MR-стенды и зачем они нужны

• Предпосылки к внедрению MR-стендов в нашей компании

• Выбор стека для создания виртуальных окружений

• Задачи, которые решают MR-стенды

• Интеграция MR-стендов в CI/CD

• Преимущества и недостатки MR-стендов

• Когда MR-стенды не подойдут

• Сложности при внедрении

• Вместо итогов

Что такое MR-стенды и зачем они нужны

MR-стенды — это временные окружения, созданные специально для проверки изменений, внесенных в кодовую базу через Merge Request. Они позволяют разработчикам и тестировщикам изолированно проверить функциональность новых изменений перед их слиянием с основной веткой. Тестирование на стейдж-среде несет в себе ряд проблем:

• Безопасность: Возможна потеря данных, нарушение функциональности;

• Изоляция: Нет возможности проверить изменения без влияния на стейдж-среду;

• Быстрая обратная связь: Отсутствие возможности быстро получить фидбек от коллег или клиентов до завершения работы над задачей.

Использование MR-стендов позволяет избежать этих проблем, обеспечивая безопасное и эффективное тестирование.

Предпосылки к внедрению MR-стендов в нашей компании

Перед началом работы с MR-стендами мы столкнулись с рядом особенностей, которые нужно было учесть при разработке решения:

• Большое количество разработчиков и тестировщиков. Много разной функциональности одновременно находится в разработке и тестируется на стейдж-среде, что мешает подготовке основного релиза;

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

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

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

1. Написание кода и создание Merge Request;

2. Прохождение Code Review;

3. Влитие задачи в main-ветку, после чего код оказывается на stage-окружении;

4. QA-инженеры проводят тестирование;

5. Дизайнеры проводят Design Review;

6. Заказчик проверяет реализованную функциональность;

7. Если на шагах № 4-6 возникли правки, то это требует запуска всего цикла и возврату к шагу № 1.

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

После внедрения MR-стендов нам удалось решить эти проблемы. Количество ошибок на этапе интеграции сократилось, так как каждый разработчик мог изолированно проверить свои изменения. Цикл разработки ускорился благодаря возможности быстро получить обратную связь от команды, а стабильность продакшена повысилась, т.к. каждую задачу тестировали отдельно. Также уменьшилось количество хотфиксов на продакшене. Улучшилась координация между командами разработчиков и тестировщиков, что способствовало более слаженной работе и повышению качества конечного продукта. Подтверждение тому – CSI продукта, который имел положительную динамику в 2024 году по сравнению с 2023-им.

Выбор стека для создания виртуальных окружений

При выборе технологий для создания MR-стендов мы учитывали совместимость с существующей инфраструктурой, стоимость владения и поддержки, а также легкость масштабирования. Рассматривались различные варианты, включая Kubernetes для оркестрации контейнеров, GitLab CI/CD для автоматизации сборки и деплоя, и S3 для хранения статики.

Мы остановились на этом стеке по нескольким причинам. Kubernetes предоставил необходимую гибкость и масштабируемость, позволяя эффективно управлять контейнерами и ресурсами. Интеграция с GitLab упростила процессы CI/CD, обеспечив единое место для управления кодом и сборками. Использование S3 в Yandex Cloud для хранения статики показало высокую надежность и доступность, что важно для быстрого доступа к ресурсам.

С финансовой точки зрения, выбор этого стека привел к экономии времени при настройке и поддержке инфраструктуры. Нам не пришлось поднимать новые ресурсы для этого. На одном проекте мы экономим около 10 тысяч рублей в месяц только на инфраструктуре (хотя тут куда важней, что у нас уменьшился релизный цикл). Точные цифры мы не приводим, но общее снижение затрат было ощутимым и положительно сказалось на бюджете проекта. Плюс, время тестирования отдельных функций снизилось на ~40%, а также уменьшилось количество возникающих визуальных ошибок на проде на 28% и уменьшилось количество хотфиксов на 70%.

Задачи, которые решают MR-стенды

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

Интеграция MR-стендов в CI/CD

Интеграция MR-стендов в наш CI/CD процесс была реализована следующим образом. При создании Merge Request разработчиком в GitLab автоматически запускался пайплайн. Собирался Docker-образ с изменениями, после чего статические файлы приложения загружались в S3. Приложение становилось доступным по уникальному URL, что позволило команде просмотреть и протестировать изменения без задержек и сложностей.

Преимущества и недостатки MR-стендов 

Внедрение MR-стендов принесло множество преимуществ. Быстрота развертывания новых окружений позволила ускорить процесс разработки (TTM для одной задачи снизился на 18,96%). Изолированность изменений обеспечила возможность тестировать каждое изменение отдельно, снижая риск конфликтов и ошибок. Это также уменьшило риски для продакшена, поскольку тестирование проводилось в отдельных средах. MR-стенды упростили параллельную разработку нескольких задач, а минимальные изменения в инфраструктуре сделали их реализацию более доступной.

Однако были и некоторые недостатки. Нам потребовался wildcard-домен и также было необходимо настроить отдачу статики из S3, динамически получая адрес из домена. Кроме того, возникала нагрузка на существующий инстанс бэкенда, если использовался один и тот же для всех стендов, что могло привести к снижению производительности.

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

Когда MR-стенды не подойдут

MR-стенды могут быть избыточными в небольших проектах с ограниченным числом разработчиков (2-3 человека), где нет необходимости в параллельном тестировании множества изменений. В таких случаях затраты на их внедрение и поддержание могут не оправдаться.

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

Сложности при внедрении

При внедрении MR-стендов мы столкнулись с некоторыми особенностями, которые нужно было поменять в текущей интеграции:

• Настройка пайплайна — мы начали собирать образ в merge-request, вытаскивать весь статический контент сайта и загружать его в S3;

• Динамическое определение адреса, по которому нужно обращаться за статическими ресурсами, чтобы отрендерить веб-приложение. То есть, мы стали извлекать из wildcard-домена ключ, по которому хранится статический контент в S3 Яндекса.

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

Вместо итогов

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

P.S. Технические подробности реализации MR-стендов ожидайте во второй части статьи.