Хабрахабр

От идеи до релиза. Детальный опыт фронтенда Маркета

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

Сегодня я расскажу читателям Хабра о нашем опыте решения этих задач. Меня зовут Александр, я руковожу одной из групп разработки интерфейсов в Яндекс.Маркете. Также рассмотрим пример доставки фичи в продакшн.

Команда

Яндекс.Маркет — крупнейший в России ресурс подбора товаров и сравнения цен. Каждый день им пользуются 3,5 миллиона человек — они планируют здесь свои будущие покупки, обсуждают товары и помогают другим людям сделать правильный выбор.

Да-да, 40 человек — это только фронтенд Маркета, а ведь есть ещё и фронты двух других наших проектов — маркетплейсов Беру и Bringly. Сейчас в Яндекс.Маркете работают 40 фронтенд-разработчиков, и их число растёт. В 2005 году в Маркете было всего 5 разработчиков, представляете?

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

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

Схема контуров фронтенда Маркета

Идеи

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

Собранные идеи проходят оценку по фреймворку GIST + ICE. Чтобы ничего не потерять, все мысли мы заносим в отдельную очередь в Трекере — наш банк идей. Подробнее об этом методе рассказал мой коллега. Мы оцениваем потенциал каждой идеи и трудозатраты на реализацию, чтобы решить, за что стоит браться в первую очередь.

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

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

Процесс

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

Макеты от дизайнера контура получены и выглядят как-то так: Предположим, что бэкендеры контура уже сделали свою работу, нейросеть обучена, API готов, проверен и развёрнут в тестовом окружении.

Макет карусели рекомендованных товаров

Осталось сделать работу на фронтенде и доставить нашу карусель пользователю.

Фронтенд живёт в облаках Яндекса в нескольких ДЦ. Фронтенд Маркета представляет собой web-клиент и stateless NodeJS-сервер, за которым расположены десятки других бэкендов: поиск, рекомендательные сервисы, аналитика, UGС-контент и прочее. NodeJS-приложение исполняется в контейнерах, а благодаря его stateless-природе его можно масштабировать горизонтально как нам нужно:

Схема устройства фронтенда Яндекс Маркета

Вести разработку на одном языке и в одной экосистеме — очень эффективно. Фронтендеры Маркета разрабатывают и серверную часть — на NodeJS, и клиент — на React + Redux. Если вы ещё думаете над унификацией своего стека технологий между сервером и клиентом, попробуйте — в этом есть смысл.

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

Код-ревью у нас является обязательным процессом. Когда это сделано, разработчик создаёт пул-реквест и отправляет свой код на код-ревью. О том, как мы ускоряли код-ревью, можно почитать здесь. Чтобы он не зависал, у нас даже есть рекомендованный SLA на его проведение.

На нашем Github живёт бот, который помогает организовать ревью кода. Разработку фронтенда мы ведём на GitHub Enterprise, доступном только во внутренней сети. Бот сам находит ревьюеров, связывается с ними в мессенджере, добавляет их на GitHub, управляет статусом тикета в Трекере и, если нужно, призывает автора кода.

Проходит масса автоматизированных проверок: линтеры, форматеры, unit-тесты. В момент создания пул-реквеста на GitHub происходит очень многое: в тестовом окружении поднимается демо-стенд с обновлённым Маркетом, а в тикет задачи доставляются ссылки доступа к этому стенду. Если обнаруживается какая-либо деградация, детальный отчёт о ней сразу же доставляется в тикет задачи: Прогоняются E2E-тесты, автоматически анализируются клиентские метрики приложения.

Пример автоматизированных проверок на GitHub

Если все проверки прошли штатно, тикет автоматически переводится в статус «Можно проверять», и задача появляется на дашборде у QA-команды.

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

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

Как это происходит? Итак, наша карусель рекомендованных товаров едет в релиз.

Начинает работать релизный пайплайн. Дежурный QA-инженер жмёт релизную кнопку. В Трекере создаётся релизный тикет, а на GitHub — релизная ветка. Презентацию доклада о релизных процессах можно посмотреть здесь. В тестовом окружении поднимается стенд с новой версией Маркета. В неё автоматически вливаются все пул-реквесты, прошедшие проверки. Например, нагрузочное тестирование постоянной нагрузкой и нарастающей до разладки тестируемого приложения. На этом стенде проходят все упомянутые выше автоматизированные проверки плюс масса дополнительных. Все логи проверок анализируются на лету, формируются понятные отчёты, которые сразу же доставляются в релизный тикет:

Пример отчета со статусами проверок в релизе

В тестовом окружении на стенде с новым релизом QA проходит и ручное тестирование. QA-инженер видит все стадии, одним взглядом может оценить результаты массы проверок. Мы часто проводим A/B-тестирование нового функционала и не пишем на него E2E-тесты.

Так выглядит релизный пайплайн (кликабельно):
Схема релизного пайплайна фронтенда Маркета

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

Они самостоятельно анализируют логи приложения, ищут в работе сервиса аномалии и деградации, следят за клиентскими метриками. В момент раскладки на бой работа роботов продолжается. Мониторинг логов продолжается ещё некоторое время после релиза, а в тестовом окружении уже проходит проверки следующая версия Маркета.

В его распоряжении большое количество графиков — мы используем Graphit и Grafana. За здоровьем Маркета после релиза следит и сам дежурный QA. У нас также есть и отдельная группа людей — группа здоровья Маркета. На графиках есть всё: от общего фона 500-к до ошибок NodeJS-приложения при общении с различными бэкендами в разрезе по ДЦ. Она 24/7 следит за метриками боевого кластера Маркета.

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

В этот момент наши пользователи уже видят подобранные для них товары, а контур работает над новой идеей.

Вот так выглядит наша карусель на сервисе:

Скриншот главной страницы Яндекс Маркета

Вместо заключения

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть