Сегодня давайте расскажу о
AWS Device Farm, ибо я плотно работал с этим сервисом больше года. Сервис представляет собой мобильные девайсы в облаке. Там есть как Android, так и iOS. Основной кейс - тестирование мобильных приложений на большом парке реальных устройств.
В целом я остался доволен сервисом. Но в процессе были набиты и шишки тоже 😊
Основные моменты, которые я для себя вынес:
- Если можно тестировать на эмуляторах, то надо тестировать на эмуляторах. Реальные девайсы - это крайне нестабильная штука и прибегать к ним надо только когда есть реальная потребность. В большинстве случаев я уверен, что это НЕ НУЖНО. Кроме того, масштабировать эмуляторы намного проще.
- Время ожидания девайса. Это один из неприятных моментов, т.к. над этим нет контроля. Может занимать от нескольких минут до бесконечности. По факту, все же где-то внутри сервиса есть некий таймаут, который зафейлит запрос девайсов если их не получается долго найти, но речь может идти о нескольких часах ожидания. Представьте юзкейс, вы запустили тесты, они ждут девайсов, недождались их и через час упали. Время фидбека становится ОЧЕНЬ длинным.
Решений тут несколько:
- Самое простое - это использовать
private devices. В этом случае вы получаете девайсы, которые доступны только для вас. Оно же самое дорогое :)
- Старайтесь использовать более старые модели. За самыми последними девайсами всегда стоит очередь.
- Я использовал подход, который назвал
device pool sharding и подробно описали
в посте в блоге- Интеграции со сторонними тулами/сервисами. В целом у AWS это одно из главных достоинств, но у данного сервиса с этим все довольно печально. Если с прошлого года ничего не поменялось, то есть только плагин для
Gradle и
Jenkins. Если вдруг вам надо собирать iOS приложение в TeamCity, то сорян. Я в свое время написал
тулзу devicefarm-ci-tool как раз для этих целей. Можете пользоваться ей если решили использовать Device Farm.
- С саппортом для этого сервиса все было очень плохо. Это при том, что у компании где я работал был самый крутой и дорогой support contract oт AWS. По опыту, на саппорт лучше не расчитывать даже если вы платите деньги. Если же вы не платите, то саппорта у вас по сути не будет в AWS, тут все просто 😀
