Релиз нельзя откатить с телефона пользователя. Эдуард Оболенский об особенностях мобильной инфраструктуры в бигтехе

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

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

Как устроена мобильная разработка в Yandex InfrastructureКак устроена мобильная разработка в Yandex Infrastructure

В идеальном мире SDLC‑цикл в мобильной разработке выглядит как последовательность следующих этапов:

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

Как происходит сборка мобильного приложенияКак происходит сборка мобильного приложения

Сборке приложения предшествует большая подготовительная работа. Вот лишь часть того, что нужно иметь на сборочном агенте:

• Android SDK/NDK версии X
• Xcode версии Z
• Ruby, Python, Jq, Curl, Wget, Brew
• Emulator/Simulator
• VirtualBox
• Docker и многое другое

В целом флоу сборки выглядит так:

Когда рабочая версия аппа готова, переходим к этапу тестирования.

Тестирование приложенияТестирование приложения

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

Наша команда работает с фермами реальных мобильных устройств: здесь размещаются самые популярные устройства в разных ценовых категориях.

Железо оркестрируется с учётом особенностей приложения. Весь кластер железа нужно поддерживать: регулярно обновлять ОС и софт до актуальных версий, контролировать стабильность работы оборудования и при необходимости менять комплектующие.

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

Сам процесс развёртывания автотестов на мобильных устройствах можно представить так:

Длительность тестирования зависит от специфики приложения. Если в одном случае достаточно 1–7 часов, то в другом может потребоваться 24 часа. Важно убедиться, что во время тестирования все мобильные устройства отработали корректно.

Почему нельзя всё тестирование перевести на автоматику, ведь порой мы имеем дело с тысячами устройств?

Во‑первых, есть вендор‑специфика каждого проекта (не только баги).

Во‑вторых, писать тесты для автоматики дорого и долго (особенно UI), а в графике и анимации тоже бывают баги.

Стоит учитывать и сложность интеграционных сценариев.

Подписатор (Signer) — между сборкой и дистрибуциейПодписатор (Signer) — между сборкой и дистрибуцией

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

На этом этапе есть много нюансов. Главное — следовать требованиям безопасности: например, нельзя хранить подпись вместе с исходным кодом приложения.

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

Дистрибуция и релизы приложенияДистрибуция и релизы приложения

Приложение протестировано, но прежде чем отправить его в сторы, нужно снова проверить, всё ли работает корректно.

Этапы релиза в мобильном мире выглядят так:

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

А затем — такие:

И такие.

Отправка приложения в сторыОтправка приложения в сторы

Перед выходом приложение попадает в сторы на ревью. Проверка может занимать часы и дни, и только потом релиз постепенно катится на девайсы пользователей.

Наша команда отвечает за представление приложений в Apple App Store Connect, Google Play Market, RuStore, в Galaxy Store, Huawei Store, Xiaomi Store и других магазинах. При публикации аппов мы учитываем нюансы сторов. Например, в каждом сторе — разные API. В Play Market часто используем API фронтенда, в App Store Connect — свой менеджмент сертификатов, девайсов и свойств приложений. RuStore делает хороший API, но здесь тоже есть своя специфика.

Метрики и планированиеМетрики и планирование

Итак, приложение выпустили. Что дальше? Нужна realtime‑аналитика, чтобы отслеживать стабильность работы приложения. Только один апп может создавать 35 млрд событий в сутки. Как оперативно контролировать такой масштаб?

Для получения объективной картины мы диверсифицируем источники сбора данных о работе приложения, в том числе получаем информацию из сторов.

Среди инструментов сбора аналитики:

• AppMetrica — наша внутренняя аналитика
• Firebase — платный доступ к SQL
• Tracer — от коллег из ВКонтакте

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

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

Какие инструменты помогают нам в работе над приложениямиКакие инструменты помогают нам в работе над приложениями

Инструментов множество, но есть сервисы, без которых наша стабильная работа невозможна.

• Signer — для подписи приложений (Android, iOS, IoT и Linux)

• Mobile Market Manager

  • Управляет ролями и доступами к аккаунтам
  • Предоставляет отдельный фронтенд для доступов
  • Оркестрирует все магазины с единым внешним API для пользователей
  • Трекает статусы приложений

• Системы управления зависимостями Mobile Registry — централизованный общий подход к работе с внешними и внутренними пакетами, политика карантина и паблишинг новых пакетов

• EventBus — для отслеживания статуса приложения в сторах по версиям из продуктовых бэкенд‑сервисов

• Release Train

  • Стейтфул‑бэкенд и CLI к нему
  • Управляет поведением релизов
  • Объединяет релизы в разных сторах в единый флоу
  • Плотная интеграция с CI/CD‑пайплайнами

Занимаетесь мобильной разработкой? Приходите в нашу команду: откликайтесь на вакансии разработчика бэкенда в команду Hyperenv и разработчика на Kotlin в мобильную платформу DevTools.