Почему готовые мобильные фермы не подошли
У нас в Сбере больше 13 офисов разработки и свыше 50 мобильных приложений в работе. Мы посчитали, что для тестирования нам нужно больше сотни разных смартфонов, а средняя цена одной модели — 40 000 рублей. К расходам на покупку прибавляются траты на логистику, если команда работает в распределённом режиме или на удалёнке.
В нашем случае покупать реальные устройства в таком количестве нерентабельно, поэтому решили использовать мобильные фермы. На рынке уже есть несколько готовых решений. Мы выбирали из тех, где была реализована трансляция.
Рассматривали два основных варианта:
- SaaS от зарубежных вендоров: AWS Device Farm и BrowserStack. Продукты не подошли из-за условий безопасности или недоступности тестового окружения.
- Проекты в Open Source: Open STF и Device Farmer (Fork). Полноценно перейти на это решение также не удалось. Device Farmer работает только для Android, а нам нужно тестировать приложения в том числе для iOS. Кроме того, для нас важно устанавливать подписанные тестовые приложения. По сути, Device Farmer — это монорепозиторий и монодистрибутив, на запуск которого влияет огромное количество параметров. А нам был нужен продукт с гибкой сервисной архитектурой.
Стало понятно, что надежды на SaaS и Open Source не оправдались. Поэтому решили разработать своё решение.
Как мы делали свою мобильную ферму
Сначала расскажу о том, что нам понадобилось, чтобы собрать собственное решение.
- Команда. Разработчики, а также специалисты техподдержки, которые могут устранить физическую поломку. Мы работаем с консумерскими устройствами, которые изначально не рассчитаны на продакшен-нагрузку. Поэтому важно, чтобы специалист мог подстраховать и минимизировать возможные технические сбои.
- Железо. Компьютеры Mac, мобильные телефоны, кабели, различные USB-хабы с отдельным питанием, бесперебойники, стойки, сменные аккумуляторы. Для Android подойдёт компьютер на Linux. И инструменты, чтобы со всем этим работать.
- Open Source проекты. Нам понадобились Appium, Libimobiledevice и ffmpeg. Appium отвечает за автоматизацию устройств, Libimobiledevice — это вспомогательная утилита, а ffmpeg — для работы с видеопотоком.
- Вендорские решения. Для работы с iPhone — Xcode, для Android — ADB из Android Studio.
- Инструменты разработки. Наше приложение написано на Node.js и TypeScript, на фронтенде — React.js, в качестве баз данных — PostgreSQL, интерактив и real-time — за счёт Server Sent Events. Всё это упаковано в Docker и K8s/OpenShift.
- Помещение. Важно обеспечить электропитание достаточной мощности, чтобы не выбивало пробки, а ещё систему вентиляции: смартфоны не должны перегреваться. Следить за пожаробезопасностью тоже обязательно.
- Сеть. Нужна стабильная связь между физическими устройствами и облачным решением. Понадобится Ethernet или Wi-Fi для Mac, а также доступ через Wi-Fi для телефонов.
С какими проблемами столкнулись
Не все нюансы удалось учесть при подготовке, поэтому в процессе мы столкнулись с рядом сложностей.
- Аккумуляторы выходят из строя. Из-за интенсивной работы они нагреваются, вздуваются и деформируют устройство. Приходится менять аккумуляторы, чтобы продолжать тестировать приложения на всех устройствах.
- Экраны выгорают. Смартфоны работают 24/7, поэтому на матрице остаются следы от интерфейса. Этот дефект не влияет на качество трансляции.
- Неэффективный кабель-менеджмент. Чтобы собрать на одной стойке несколько десятков смартфонов, пришлось потратить время на аккуратную прокладку всех кабелей — это упрощает обслуживание и замену устройств.
- Много времени уходит на настройку. У каждого телефона нужно включать режимы разработчика или автоматизацию интерфейса. Такие издержки кажутся незначительными, но в масштабе всего парка устройств тратится достаточное количество времени. Это тоже нужно учитывать.
Над чем работаем сейчас и какой план развития
Сейчас мы работаем над оптимизацией процесса тестирования. В частности, ищем решение, чтобы сбрасывать данные с устройства между сеансами без полного отката настроек, передавать звук, даже если на устройстве нет разъёма 3,5 мм, и перехватывать трафик у тестовых приложений на устройстве.
В планах работа над подключением через ADB к удалённым устройствам для дебага и подключением Chrome DevTools для Android, если нужно исправить фронтенд на мобильном устройстве. Также попробуем WebRTC для трансляции экрана. В дальнейшем интегрируем эти фичи в CI/CD-разработку.