От ручной работы к автоматизации: наш путь к идеальной доставке сборок Flutter

Привет! Меня зовут Роман, я руковожу Flutter-разработкой в диджитал-агентстве Адикт. Мы занимаемся созданием мобильных приложений, а также поддержкой и развитием уже существующих проектов. Одной из ключевых задач в работе является быстрая и надежная доставка сборок приложений тестировщикам и клиентам. Делимся опытом.

Вынесем за скобки более сложные процессы доставки сборок через полноценные CI/CD-инструменты — об этом поговорим в конце статьи.

Сейчас представим, что у нас небольшая команда, и доставка обновлений не требует сложных девопс-процессов (ну, как у 80% команд).

Дополнительные вводные: разработка мобильных приложений ведется на Flutter, версионность кода в Git. Активно используются ветки для работы над фичами, а основной канал коммуникации команды — Telegram. Для удобства работы настроено несколько стендов с бэкендом: тестовый наш, тестовый клиента, препрод и прод.

Как обычно выглядит работа:

В целом ничего сложного, но как можно ускорить этот процесс и свести его к нескольким кликам?

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

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

Для этого нужен экран с настройками, где первой опцией будет переключение сервера.

Что мы решили на этом этапе:

Для упрощения процесса сборки и отправки билдов приложения тестировщикам и клиентам мы сделали следующее:

Так как размер сборки превышает 50 МБ, отправить её через бота не получится. Чтобы решить эту проблему, мы сразу загружаем файл в Google Диск.

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

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

Для автоматизации процесса мы разработали скрипт, который использует файл окружения со следующими параметрами:

При запуске бот выполняет следующие действия:

1. Авторизация в Google API:

— Бот проверяет авторизацию с помощью библиотеки googleapiclient. Для этого используется файл credentials.json, который содержит ключи доступа к Google API.

— Если авторизация успешна, бот получает доступ к папке на Google Диске, указанной в файле окружения.

2. Мониторинг Google Диска:

— Бот периодически проверяет наличие новых сборок в папке Google Диска.

— Если обнаруживаются сборки, которые ещё не были отправлены в Telegram, бот формирует сообщение с информацией о сборке (тип, номер версии, коммит, ветка, ссылка на Google Диск) и отправляет его в указанный чат Telegram.

3. Мониторинг локальной папки:

— Бот также мониторит локальную папку для новых сборок.

— При появлении новой сборки, бот автоматически загружает её в указанную папку на Google Диске.

— После успешной загрузки бот формирует и отправляет сообщение в Telegram с деталями сборки.

4. Обработка ошибок и уведомления:

— В случае недоступности сервера или изменения данных, бот отправляет соответствующие уведомления в Telegram.

— Эти уведомления помогают команде оперативно реагировать на проблемы и минимизировать время простоя.

Все просто! 😇

Еще раз, мы можем настроить CI/CD в Git-репозитории, но давайте сравним решения:

CI/CD:

Наш скрипт:

Внедрение CI/CD в Git-репозитории значительно упростит и ускорит процесс сборки и доставки приложений, сведет к минимуму ручные действия и уменьшит вероятность ошибок. Интеграция с Telegram дополнительно облегчает коммуникацию и информирование команды, делая процесс более прозрачным и оперативным. Однако для небольших команд и проектов с ограниченными ресурсами, где нет сильной devops-команды, использование скрипта автоматизации может быть более предпочтительным из-за своей простоты и минимальных требований к настройке.

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

GitHub Actions

Bitrise

CircleCI

Fastlane

App Center by Microsoft

Jenkins

Travis CI