Введение. О мобильной разработке и об инструментах, которые мы используем

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

Рассмотрим на примере мира iOS. Когда ты только собираешься начать программировать, тебе, конечно, нужна среда разработки. Берем самый очевидный вариант – Xcode. Далее ты пишешь первое приложение, и теперь тебе надо его как-то запустить. Тут ты знакомишься с iOS Simulator. Через какое-то время ты уже в команде и делаешь задачи. Вот надо посниффить трафик – разбираешься в Charles. Влезаешь в пуши – узнаешь о Pusher. Надо подебажить приложение, а напрямую подключиться из Xсode нет возможности – идешь в Console. Начинаешь заниматься релизом – постигаешь Fastlane. Fastlane на CI ломается – постигаешь Transporter.

Также я думаю, что все мобильные разработчики рано или поздно столкнутся с Firebase и другими Google Services. Firebase – это продуктовая аналитика, анализ краш-логов, продуктовые пуши и маркетинговые рассылки, remote config, тестовые сборки и еще много чего. Я думаю, все прекрасно понимают важность каждого из этих элементов в процессе разработки и поддержки приложения.

Проблема с которой мы почти все столкнулись

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

Как мы подошли к этой проблеме

Решение выглядит очень простым с точки зрения формулировки, но сложным с точки зрения реализации. Нам надо:

• Проверить все сторонние зависимости в нашем приложении на возможность их отключения;

• Для выбранных зависимостей подобрать замену или замены с аналогичной функциональностью;

• Выбрать среди аналогов лучший. Критерии в каждом случае будут свои.

В процессе анализа зависимостей приложения мы выявили ряд инструментов, которые в теории могли бы быть отключены. Как пример, первым и самым явным можно назвать Firebase. Ранее в статье уже было упомянуто, за что отвечает данный инструмент, таким образом, риск его отключения ставил под сомнение дальнейшую возможность поддержки приложения.

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

Продуктовая аналитика

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

AppMetrica

Инструмент от Яндекса, достаточно известный. Удобный и легко интегрируется. Данные с него в своей работе у нас используют продакт-менеджеры, потому что в AppMetrica наглядные и структурированные дашборды и графики из коробки.

Но после анализа от аналитиков, поступило предложение интегрировать Snowplow.

Snowplow

Это корпоративная платформа для маркетинга и анализа продуктов. Здесь собираются все метрики для построения аналитических дашбордов по требованиям. Snowplow обладает большей функциональностью, чем AppMetrica, но всю эту функциональность надо дополнительно настраивать. Ей пользуются дата-аналитики.

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

Крашлитика и аналитика производительности

Хорошим и единственным аналогом для рассмотрения был Sentry. Удобный и неприхотливый в развертывании кросс-платформенный мониторинг приложений с акцентом на отчеты об ошибках. Является self-hosted решением, что гарантирует зависимость работоспособности сервиса только он нас.

Уведомления

Замена механизма для push-уведомлений была одним из самых болезненных вопросов, потому что в случае блокировки со стороны APNS альтернатив в iOS-мире нет. Только переход на СМС, что является достаточно затратным вариантом.
Отказавшись от Firebase для управления рекламными пушами, мы перешли на AppMetrica. Для сервисных пушей мы использовали и используем собственную реализацию на бекенде. Почему мы не заиспользуем это решение для рекламных пушей? Потому что для этого нужно поднять документацию по использованию и убедиться, что для рекламных пушей не понадобятся доработки. А бекенд-разработка сейчас занимается более приоритетными задачами.

Remote Config

Напомню, что remote config – это набор настроек, приходящих на мобильный клиент при старте приложения. Он настраивается на вебе и может быть разным для отдельных пользователей. Через remote config мы реализуем фича-флаги, A/B тесты и дополнительные настройки. При анализе альтернатив Firebase, выбор оказался достаточно большим.

Flagsmith
Open Source Feature Flagging and Remote Config Service

Плюсы:

• Open Source

• Наличие клиентского SDK

• Self-hosted и on-prem

Минусы:

• Ограничение в 50 000 запросов в месяц

Явно не подходит под наши масштабы.

ConfigCat
Managed feature flag service

Плюсы:

• Open Source

• Удобный UI

• Есть поддержка A/B тестирования

• Наличие опенсорсного клиентского SDK

Минусы:

• Ограничение в 5 000 000 запросов в месяц

Все еще мало запросов.

Flipt
An open-source, on-prem feature flag solution 

Плюсы:

• Open Source

• On-prem

Минусы:

• Нет SDK под iOS

Достойный вариант, без ограничений. Но проигрывающий по количеству плюсов следующим вариантам.

Unleash
Is the open source feature toggle service

Плюсы:

• Open Source

• Удобный UI

• Есть поддержка A/B тестирования

• Данные загружаются json-ом

Минусы:

• Open Source версия очень урезанная по сравнению с платной

• Отсутствует сегментация

Мы ищем не платную версию.

Flagr
Is a feature flagging, A/B testing and dynamic configuration microservice

Плюсы:

• Open Source

• Бекенд с красивой оберткой

• Self-hosted и on-prem

Минусы:

• Нет SDK под мобилку

• Не самый удобный UI

Наличие всех необходимых плюсов, отсутствие ограничений на количество запросов и доступность всего функционала в Open Source версии останавливает наш выбор на Flagr. Хоть здесь и отсутствует SDK под мобилку, для данного сервиса это не критично. Мы уже написали собственную реализацию в рамках одного спринта. Подняли сервер с вебом. Через него загрузили данные флагов и настроек. При старте приложения через наше SDK делается запрос и подтягивается Remote Config.

Рассылки тестовых сборок

На данный момент дев сборки собираются через скрипты с помощью fastlane на GitLab CI. Далее тестировщики забирают сборки из артефактов.

Google Maps

Также для полноты картины, важно отметить уход от Google Maps. Мы давно уже поглядывали на 2GIS, и теперь же нам представился шанс сделать переход. Он вышел удачным, с сохранением всей функциональности. Справедливости ради, интерфейс взаимодействия с 2GIS оказался скуднее, чем у Google Maps. Что вызвало небольшие трудности при интеграции.

В целом, картами от Google пользуется огромное количество разработчиков. За время их существования на просторах форумов вида StackOverflow накопилось очень много вопросов (как тривиальных, так и не очень) по части использования данного провайдера. В случае с 2GIS на помощь приходит только раздел Issues на Github. Уверены, что у коллег из 2GIS все еще впереди и их продукт будет становиться только лучше и лучше.

Заключение

Работа по поиску инструментов шла, на наш взгляд, плодотворно. Мы внедрили и уже активно используем инструменты, о которых рассказали выше. Но есть и нерешенные задачи, с которыми мы разбираемся или планируем разобраться в ближайшее время. “Доставка” тестовых сборок по сути переведена в ручной режим. Также еще думаем над более удобном инструментом для A/B-тестирования, потому что Flagr в этом плане не очень практичен. Возможно, рассмотрим написание своих инструментов.

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