В первой части гайда RuStore по доставке фичей мы — техлид backend-команды Rustore Григорий Рябов и руководитель команды разработки RuStore: направление платежей, Александр Котельников, разобрали подготовительные этапы, которые закладывают прочный фундамент для всей разработки: от Kick-off и архитектурного планирования до Technical Design и тестовой стратегии.
Теперь переходим к самой насыщенной и ресурсозатратной фазе — реализации. В этой части мы делимся практическим подходом к организации разработки, интеграции, автоматизации тестов и проведению финального тестирования. Именно здесь идеи превращаются в работающий, отказоустойчивый код, готовый к продакшену.
Напомним, зачем мы вообще взялись за этот гайд и кому он будет полезен:
тем, кто хочет навести порядок в процессе доставки фичей;
тимлидам и менеджерам, которым нужна предсказуемость;
инженерам, которые хотят меньше хаоса и больше системности.
Всё, что описано, мы опробовали на собственных фичах в RuStore. Мы не один раз ошибались, дорабатывали, улучшали и теперь делимся рабочим подходом, который помогает нам запускать фичи спокойно, стабильно и уверенно.
Разработка и интеграция: превращаем идеи в код
Зачем нужен этот этап?
У нас есть утверждённый подробный Technical Design и понятные входные данные. Пора кодить, тестировать и интегрировать фичу в систему.
Цель этапа — реализовать фичу в соответствии с Technical Design, интегрировать с другими компонентами системы, обеспечить отказоустойчивость, мониторинг и подготовить код к тестированию и последующему релизу.
Этот этап проходит параллельно с тест-дизайном: пока разработчики пишут код, тестировщики готовят тестовые сценарии. Такой подход позволяет ускорить процесс валидации фичи.
Как проходит работа
1. Подготавливаем окружение
Готовы ли нужные стенды (Dev, Stage, Test)?
Есть ли доступы ко всем сервисам?
Настроены ли переменные окружения?
2. Пишем код
Разработка ведётся по задачам из Technical Design.
Внедряем feature toggle для безопасной активации.
Пишем основную бизнес-логику.
Интегрируемся с другими компонентами — работа с API, базами данных, очередями сообщений.
Настраиваем логирование, сбор метрик, алерты.
Работаем с доработками и исправлениями — перед выкладкой фиксируем все найденные недочёты.
Инжекты в изначально декомпозированные планы запрещены — любые изменения должны проходить отдельный процесс согласования.
Планируем дополнительный этап работы при необходимости (для тилида) — управляем ожиданиями заинтересованных лиц.
3. Проверяем и тестируем код
Прогоняем локальные тесты.
Проверяем, не сломали ли другие части системы.
Результаты этапа
Готова реализация фичи.
Feature toggle работают корректно.
Задачи готовы к тестированию.
Настроены механизмы логирования, мониторинга и алертов.
Подготовлен код, учитывающий отказоустойчивость и обработку ошибок.
Возможность гибкого включения и отката фичи через feature toggle.
Проверочный вопрос этапа: если фича упадёт в проде — мы поймём, почему? Сможем откатить? Если нет, надо улучшить мониторинг и логи!
Наш опыт
Этот этап содержит множество нюансов, о которых можно забыть. Что мы успешно раньше и делали. Сейчас же у нас есть структурированный чеклист, который помогает не терять детали: с ним мы ускорили процесс разработки и значительно снизили риски.
Feature toggles позволяют нам лить код в мастер, не влияя на релизные процессы, а также дают отложенное тестирование и возможность ограниченной раскатки на прод. Всё это — 100% уверенность в работе фичи и ее мониторинга.
Разработка автотестов и реализация бизнес-метрик
Зачем нужен этот этап?
Автоматизация тестирования и настройка бизнес-метрик помогают гарантировать стабильность работы фичи и обеспечить контроль её эффективности после релиза. Этот этап минимизирует вероятность регрессионных багов, ускоряет выпуск обновлений и позволяет оперативно реагировать на изменения в поведении системы.
Цель этапа — обеспечить автоматизированный контроль качества и мониторинг эффективности фичи, чтобы команда могла оперативно выявлять и устранять возможные проблемы.
Без автотестов разработка замедляется, так как каждое изменение требует ручной проверки. А без метрик невозможно оценить влияние фичи на пользователей и бизнес-показатели.
Как проходит работа
1. Реализуем автотесты и метрики
Покрываем ключевые сценарии юнит- и интеграционными тестами.
Для критических сценариев разрабатываем API-тесты и проверки с UI (web/mobile).
Настраиваем CI/CD для автоматического запуска тестов.
Настраиваем сбор ключевых бизнес-метрик и интегрируем их в систему аналитики.
Настраиваем дашборды и алерты в Grafana, Kibana или другом инструменте мониторинга.
2. Проверяем корректность работы тестов и мониторинга
Автотесты успешно проходят в CI/CD без ложных срабатываний.
Бизнес-метрики корректно собираются и анализируются.
Алерты на критические ошибки и аномалии работают без избыточного шума.
Результаты этапа
Готовый набор автотестов, покрывающий ключевые сценарии.
Запуск тестов автоматизирован в CI/CD, снижая время на регресс.
Настроены бизнес-метрики и дашборды, позволяя анализировать поведение пользователей.
Рабочие алерты, сигнализирующие о сбоях и критических изменениях в системе.
Этот этап критически важен для устойчивости и наблюдаемости системы. Чем раньше тесты и метрики внедрены в процесс, тем быстрее можно находить и устранять проблемы.
Тест-дизайн и тестирование
Зачем нужен этот этап?
Теперь у нас есть общий тест-план, но он определяет только стратегию тестирования. На этом этапе необходимо детализировать тест-кейсы, зафиксировать ключевые сценарии, подготовить тестовые данные и приступить к тестированию. Это позволит минимизировать риски возникновения дефектов в продакшене и повысить качество продукта.
Цель этапа — проверить работоспособность фичи, выявить дефекты, убедиться в соответствии бизнес- и техническим требованиям и подготовить её к выпуску.
Этот этап проходит параллельно с разработкой, что позволяет QA-команде подготовить тест-кейсы заранее и ускорить процесс валидации фичи.
Как проходит работа
1. Определяем ключевые сценарии
Анализируем технические требования, дизайн и верхнеуровневый тест-план.
Определяем критические пользовательские сценарии.
Выявляем граничные случаи и возможные ошибки.
2. Готовим тест-кейсы и тестируем фичу
Создаём тест-кейсы и тестовые данные.
Определяем тест-планы для CI/CD.
-
Проводим тестирование:
проверяем базовые и критические сценарии;
анализируем влияние изменений на другие части системы;
фиксируем баги, передаём их в разработку.
Составляем итоговую тестовую документацию.
Результаты этапа
Готовы тест-кейсы и тест-планы.
Проверены все необходимые сценарии.
Зафиксированы результаты тестирования.
Исправлены критические баги.
Фича готова к финальной проверке перед релизом.
Быстрый тест: если QA из другой команды может взять кейс и протестировать — всё хорошо.
Наш опыт
С переходом на верхнеуровневые тест-планы мы начали гораздо точнее оценивать сроки тестирования и добиваться совпадения планов с фактом при разработке фичей. Это также помогло заранее понимать объём предстоящей автоматизации и эффективнее планировать работу над автотестами.
Раньше мы сталкивались с типичной проблемой: финальные контракты и дизайн появлялись только ближе к завершению разработки, и тест-дизайн шёл уже по следам реализации. Если же начинали раньше — нередко приходилось переписывать тест-кейсы, чтобы они отражали реальную логику работы фичи.
Внедрение единого формата тест-дизайна стало ключевым шагом. Он позволяет быстрее подключать к тестированию другие команды, ускоряет регресс, а тест-кейсы с понятной и единообразной разметкой автоматически попадают в нужные тест-планы.
Что дальше?
Во второй части гайда мы прошли путь от утверждённого Technical Design до полностью реализованной, протестированной и наблюдаемой фичи. Разработка, интеграция, автотесты, метрики и тест-дизайн — всё это не просто формальности, а важные шаги, которые обеспечивают стабильность, отказоустойчивость и предсказуемость поставки фичи.
Когда каждый этап работает как часы — прод уже не пугает, а становится ожидаемым итогом системной работы.
В третьей части гайда мы расскажем:
как подготовить фичу к релизу: от финального тестирования до disaster- и нагрузочного тестирования;
как мы настраиваем мониторинг и алерты для выхода в прод;
что происходит после релиза: как отслеживаем поведение фичи, собираем фидбек, передаём поддержку и принимаем решения о дальнейших действиях.
Если у вас есть свои подходы к процессу разработки, автоматизации и тестированию — делитесь в комментариях. Мы открыты к обмену опытом и с удовольствием обсудим, как сделать поставку фичей ещё лучше.