Когда тестирование фичей на изолированных фича-серверах ускоряет разработку, а когда — несёт лишнюю нагрузку

Спросили у трёх менеджеров из KTS и OTUS, в каких случаях тестирование на отдельных фича-серверах приносит ощутимую пользу бизнесу — ускоряет Time to Market и удешевляет запуск экспериментов, а когда — добавляет ненужный головняк.

Когда тестирование фичей на изолированных фича-серверах ускоряет разработку, а когда — несёт лишнюю нагрузку

Это Максим Павлов из KTS. Мы разрабатываем веб-сервисы и мобильные приложения на заказ. Кроме этого мы помогаем другим компаниям сделать разработку более эффективной с помощью налаживания DevOps-процессов.

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

Спросил у трёх менеджеров из KTS и OTUS, что они думают про динамические окружения, делюсь результатами.

Плюсы фича-серверов

Наталья Курбанова
Менеджер в отделе спецпроектов KTS

Тестовый сервер всегда в рабочем и актуальном состоянии

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

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

Удешевляют запуск экспериментов

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

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

Ускоряют тестирование

— На последнем проекте мы делали игру на смешивание цветов. Чтобы дойти до этой функции, нужно сначала пройти несколько экранов онбординга.

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

Никита Сучков

CIO в OTUS

Уменьшают Time to Market

— С помощью фича-серверов можно точечно отслеживать изменения по фичам и не блокировать задачи других разработчиков. Каждая ветка — это полноценное тестовое окружение, что удобно в тестировании.

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

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

Минусы фича-серверов

Потребляют больше серверных ресурсов чем единый тестовый сервер

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

Чтобы контролировать затраты на инфраструктуру, нужно следить за количеством одновременно запущенных фича-серверов. Фича-стенды с неактуальными и замороженными задачами нужно не забывать выключать.

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

Павел Глазков, тимлид разработки в OTUS

Существует лимит по включению https на доменах

— Каждая ветка разворачивается на отдельном домене, например feature-256.dev.mysite.ru. Чтобы браузер корректно показывал страницу с https, под неё автоматически выпускается бесплатный сертификат let's encrypt. У этого сервиса есть ограничение на количество выпускаемых сертификатов в неделю.

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

Павел Глазков, тимлид в OTUS

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

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

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

Павел Глазков, тимлид в OTUS

Когда фича-серверы нужны

Виктория Строгонова

Руководитель юнита корпоративных систем в KTS

Если одновременно в работе много фичей

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

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

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

Если у одного разработчика много параллельных задач в работе

— Вообще проблему нескольких задач в работе на одном разработчике лучше решать с помощью изменения процессов.

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

Когда фича-серверы не нужны

Если в команде всего один разработчик каждого профиля

— Если фронтендом занимается больше одного разработчика, то использование фича-серверов для нас в KTS — это стандарт. Бэкенд же, напротив, может выкатывать какие-то изменения сразу на тестовый сервер, потому что код бэкенда у нас покрыт автотестами, а ручное тестирование чаще всего происходит уже в связке с фронтендом.

Однако при одном фронтенд разработчике, который не ведёт одновременно много задач, внедрение фича-серверов может быть неоправданно трудозатратным.

При тестировании хот-фиксов

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

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

Такие хот-фиксы лучше сразу тестировать на общем тестовом сервере.

Максим Павлов

Управляющий партнёр в KTS

С чего начать

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

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

Мы же можем настроить динамические окружения за 2 недели.

Проконсультируем и быстро настроим фича сервера. Пишите мне в телеграм: ссылка

3131
Начать дискуссию