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

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

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

Процесс доставки сборок

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

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

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

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

1. Разработчик вносит изменения и проверяет их.

2. Создает сборку для Android.

3. Изменяет имя файла, добавляя версию, тип релиза (тест, прод) и прочую информацию.

4. Загружает сборку вручную в Telegram (таск-трекер, диск, почту, любое другое хранилище).

5. Тестировщик скачивает, устанавливает и проверяет приложение.

6. Если все в порядке, сборка отправляется клиенту.

7. Клиент также скачивает, устанавливает и проверяет приложение.

8. Если все в порядке, разработчик создает сборку с продакшн-сервером.

9. Тестировщики повторяют проверку, как на шаге 5.

10. Если все в порядке, создается сборка для iOS. Для этого разработчик с доступом к сертификатам и компьютером на macOS вручную собирает код из определенной ветки.

11. Тестирование проводится и на этой сборке.

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

Внутренняя логика приложения

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

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

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

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

1. Намного реже приходится просить разработчиков собирать приложение под разные стенды.

2. Больше не тратим время на заливку, отправку, скачивание и установку приложений.

3. Переключаемся между серверами в пару кликов.

4. Никто никого не отвлекает, чтобы проверить на продакшн-сервере.

5. Разработчики не отвлекаются от других задач для создания сборки с продакшн-сервером.

Сборка и отправка билдов приложения тестировщикам и клиентам

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

1. Создали скрипт сборки, который добавляет номер версии, ветку и коммит в название файла, а затем помещает его в определенную папку.

2. После этого сборку нужно отправить в Telegram.

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

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

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

1. Создали скрипт, который мониторит доступность серверов и присылает сообщение о том, что сервер не работает или часть данных изменилась.

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

Техническая часть

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

• Адреса серверов: указаны URL-адреса тестового, тестового клиента, препрод и прод серверов.

• Токен Telegram-бота и чат, куда бот отправляет сообщения: для аутентификации и отправки уведомлений в нужные чаты.

• Папка для мониторинга новых сборок: локальная директория, где сохраняются новые сборки.

• ID папки в Google Диске, куда бот загружает сборки: папка на Google Диске с доступом для всех, у кого есть ссылка.

• Файл базы данных sqlite3: используется для хранения состояния и метаданных о сборках.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все просто!