Как мы разработали аналог Firebase App Distribution

Ключевым показателем эффективности разработки является не только качество, но и скорость выпуска продукта для конечного пользователя. Так называемый time-to-market (TTM). Уменьшить TTM и при этом не терять в качестве при разработке мобильных приложений нам помогает методика CI/CD.

CI – непрерывная интеграция. Этот подход подразумевает частое внесение изменений в код, которые затем сохраняются в репозитории. Это позволяет чаще развертывать изменения и выявлять ошибки еще на ранних стадиях разработки.

CD – непрерывная доставка, отвечает поставку новых модулей продукта всем на разные окружения (dev, окружение заказчика и т.д).

CI/CD подразумевает непрерывное тестирование, поэтому неотъемлемой частью этого процесса является удобная и быстрая доставка сборки для тестов. На этом и хотим заострить внимание.

Как это происходит у нас

Например, разработчик хочет добавить какое-то изменение и быстро его проверить.

• Вносятся нужные правки в коде, затем изменения отправляются в GIT
• Автоматически триггерится пайплайн в TFS, который запускает сборку 
• Загружается сервис, который автоматически отправляет тестировщикам нотификацию о том, что сборка готова 
• Тестировщики скачивают нужную версию и приступают к проверке 

Для отправки нотификаций ответственным сотрудникам и загрузки сборок мы использовали сервис App Distribution, который работает в платформе Firebase от Google.

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

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

Первый вариант решения проблемы

Первым решением, которое мы решили попробовать стала установка VPN, которые тестировщики включают в момент скачивания версии. Какое-то время это помогало, но через несколько месяцев VPN тоже начали блокировать. Мы были вынуждены придумывать доработки, искать новый IP, чтобы App Distribution продолжал выполнять свои функции. Это накладывало отпечаток на работу: поиск решения занимал время, и мы теряли возможность скачать версию примерно на сутки. Кроме того, скорость с VPN значительно ниже и скачивание большой сборки занимало около часа.

Собственный сервис 

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

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

Как он работает? Разработчик приложения пишет код, делает коммиты и, когда версия готова, запускает сборку. В момент сборки создается APK – файл с приложением, который отправляется к нам на сервис и хранится в бэкенде. Там же хранятся список заказчиков, список приложений, которые им принадлежат и все сборки, которые когда-либо приходили на сервер.

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

А когда выбирается нужный заказчик, с бэкенда отправляется список всех сборок с QR-кодами. Если считать QR-код, то начнется процесс отправки приложения и оно будет установлено на устройство.

Заменил ли наш собственный App Distribution старый сервис?

Мы постепенно подключаем наши продукты к TE App Distribution, но пока не отказываемся от Firebase App Distribution полностью. Однако разработка собственной альтернативы позволяет нам иметь запасной путь, если зарубежный сервис станет нам полностью недоступен.