Когда тестирование фичей на изолированных фича-серверах ускоряет разработку, а когда — несёт лишнюю нагрузку
Спросили у трёх менеджеров из KTS и OTUS, в каких случаях тестирование на отдельных фича-серверах приносит ощутимую пользу бизнесу — ускоряет Time to Market и удешевляет запуск экспериментов, а когда — добавляет ненужный головняк.
Это Максим Павлов из KTS. Мы разрабатываем веб-сервисы и мобильные приложения на заказ. Кроме этого мы помогаем другим компаниям сделать разработку более эффективной с помощью налаживания DevOps-процессов.
Для себя мы давно внедрили фичи-серверы, на которых изолированного тестируются фичи, так как на каждом проекте у нас работают несколько разработчиков. Однако оказалось, что менеджерам со стороны не всегда очевиден бизнес-эффект от этого подхода.
Спросил у трёх менеджеров из KTS и OTUS, что они думают про динамические окружения, делюсь результатами.
Плюсы фича-серверов
Тестовый сервер всегда в рабочем и актуальном состоянии
— Динамические окружения помогают держать тестовый сервер стабильно работающим — новые изменения в него попадают только после тестирования и исправления всех ошибок.
Поэтому заказчик может в любой момент посмотреть текущую стабильную версию проекта и не слышать от команды «ой, мы там новую фичу выкатили и теперь пол-сайта не работает». Это позволяет сделать процесс разработки прозрачным.
Удешевляют запуск экспериментов
— На отдельном фича-сервере удобно креативить, потому что его всегда можно без дополнительных усилий скрыть как неудавшийся эксперимент.
Если запускать эксперимент на общем тестовом сервере, то чтобы убрать неудачные результаты с тестового сервера, придётся приложить дополнительные усилия, чтобы пересобрать тестовый сервер с нужными ветками.
Ускоряют тестирование
— На последнем проекте мы делали игру на смешивание цветов. Чтобы дойти до этой функции, нужно сначала пройти несколько экранов онбординга.
Разработчики вынесли этот функционал в отдельную ветку, где временно скрыли экраны онбординга, и разложили на отдельный фича-сервер. Поэтому я смогла быстрее смотреть и выдавать обратную связь по механике. Мы в несколько заходов докрутили механику до играбельного состояния и сэкономили время на прокликивании ненужных экранов.
Никита Сучков
Уменьшают Time to Market
— С помощью фича-серверов можно точечно отслеживать изменения по фичам и не блокировать задачи других разработчиков. Каждая ветка — это полноценное тестовое окружение, что удобно в тестировании.
В итоге за счёт фича-серверов сокращается время доставки фичей и появляется возможность параллельно работать над несколькими большими проектами в рамках единого продукта.
Это соответствует стратегии компании - быстрый Time to Market и параллельному развитию в нескольких направлениях, что позволяет OTUS достигать поставленных целей и быстро адаптироваться к изменениям.
Минусы фича-серверов
Потребляют больше серверных ресурсов чем единый тестовый сервер
— Несколько изолированных фича-серверов потребляют больше ресурсов, чем единый тестовый сервер. Если команда небольшая и количество фичей в разработке невелико, то дополнительные затраты незаметны. Однако, когда команда растёт, это различие может стать ощутимым.
Чтобы контролировать затраты на инфраструктуру, нужно следить за количеством одновременно запущенных фича-серверов. Фича-стенды с неактуальными и замороженными задачами нужно не забывать выключать.
В нашей команде у одного из разработчиков был такой метод: он создавал несколько веток и в разных ветках тестировал свои теории в рамках одной задачи. Таким образом, неожиданно для нас потребление тестовой инфраструктуры резко выросло. Понятно, что для маленькой команды — это редкое явление, поскольку не все так работают. Но такой кейс нужно держать в уме.
Существует лимит по включению https на доменах
— Каждая ветка разворачивается на отдельном домене, например feature-256.dev.mysite.ru. Чтобы браузер корректно показывал страницу с https, под неё автоматически выпускается бесплатный сертификат let's encrypt. У этого сервиса есть ограничение на количество выпускаемых сертификатов в неделю.
Всего выдаётся 50 сертификатов в неделю. Редко можно выйти за этот лимит, но это зависит от размера команды. Если команда большая и за неделю на тестирование выкатывается больше 50 фичей, то с этим можно сразу столкнуться. Если команда маленькая то можно и не столкнуться вовсе.
Нужны дополнительные усилия для того, чтобы связать изолированные ветки фронта и бэка
Часто фичи затрагивают только одну часть — либо бэкенд, либо фронтенд. В таких случаях нет дополнительных действий при запуске фича-сервера — он запускается автоматически.
Если же для тестирования фичи нужно связать ветку фронта и ветку бэка, нужно отдельно прописывать связь этих веток в переменных в пайплайне.
Когда фича-серверы нужны
Виктория Строгонова
Руководитель юнита корпоративных систем в KTS
Если одновременно в работе много фичей
— На одном проекте заказчик насколько быстро и часто менял требования, что новые правки отменяли предыдущие ещё до того как они пройдут полный цикл тестирования.
Из-за этого невозможно было держать тестовый сервер стабильно работающим — в нем скапливались недоделанные задачи. Как следствие у нас возникла проблема — мы не могли показать ничего готового заказчику по итогам нескольких месяцев разработки.
Первое решение, которое я приняла когда подключилась на проект — это тестирование на фича-серверах, так как это дает возможность держать основной тестовый сервер готовым к показу заказчику в любой момент.
Если у одного разработчика много параллельных задач в работе
— Вообще проблему нескольких задач в работе на одном разработчике лучше решать с помощью изменения процессов.
Но если всё-таки так случилось, что один разработчик постоянно переключается между несколькими задачами, то фича-серверы помогут не запутаться в изменениях каждой задачи.
Когда фича-серверы не нужны
Если в команде всего один разработчик каждого профиля
— Если фронтендом занимается больше одного разработчика, то использование фича-серверов для нас в KTS — это стандарт. Бэкенд же, напротив, может выкатывать какие-то изменения сразу на тестовый сервер, потому что код бэкенда у нас покрыт автотестами, а ручное тестирование чаще всего происходит уже в связке с фронтендом.
Однако при одном фронтенд разработчике, который не ведёт одновременно много задач, внедрение фича-серверов может быть неоправданно трудозатратным.
При тестировании хот-фиксов
— Хот-фиксы на то и хот-фиксы, что их нужно как можно быстрее дотащить до продакшена. Такие задачи не накапливаются в недоделанном виде на тестовом сервере.
Поэтому их тестирование на отдельном фича-сервере не приносит дополнительной пользы и только добавляет дополнительный шаг, который удлиняет срок доставки до продакшена.
Такие хот-фиксы лучше сразу тестировать на общем тестовом сервере.
Управляющий партнёр в KTS
С чего начать
Чтобы лучше понять, как фича-серверы решают проблемы бизнеса, можете прочитать другие статьи про этот подход:
- Как фича-серверы ускоряют Time to Market
- Как фича-серверы помогают сохранить высокую производительность при росте команды
- Как по нытью разработчиков понять, что вам нужны фича-серверы
Внедрить динамические окружения — единоразовая работа. Если в команде нет людей, которые уже раньше это делали, то средние затраты по нашим опросам занимают 4-6 человеко-месяцев в зависимости от квалификации инженеров и масштабов проекта.
Мы же можем настроить динамические окружения за 2 недели.
Проконсультируем и быстро настроим фича сервера. Пишите мне в телеграм: ссылка