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

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

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

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

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

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

Разработчик вносит изменения и проверяет их.
Создает сборку для Android.
Изменяет имя файла, добавляя версию, тип релиза (тест, прод) и прочую информацию.
Загружает сборку вручную в Telegram (таск-трекер, диск, почту, любое другое хранилище).
Тестировщик скачивает, устанавливает и проверяет приложение.
Если все в порядке, сборка отправляется клиенту.
Клиент также скачивает, устанавливает и проверяет приложение.
Если все в порядке, разработчик создает сборку с продакшн-сервером.
Тестировщики повторяют проверку, как на шаге 5.
Если все в порядке, создается сборка для iOS. Для этого разработчик с доступом к сертификатам и компьютером на macOS вручную собирает код из определенной ветки.
Тестирование проводится и на этой сборке.

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

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

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

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

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

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

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

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

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

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

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

Создали скрипт, который мониторит доступность серверов и присылает сообщение о том, что сервер не работает или часть данных изменилась.
Добавили проверку сборок в папке сборок: скрипт выгружает их в 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.

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

Все просто! 😇

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

CI/CD:

Требуется GIT сервер с поддержкой CI/CD.
Требуется сервер для хранения сборок (артефактов).
Требуется компьютер для сборки (runner).
Доступ к сборкам (артефактам) должен быть у тестировщиков и клиентов.
Сложный процесс настройки и поддержки, требующий участия специалистов.

Наш скрипт:

Требуется компьютер для сборки.
В Google Диске есть лимиты на общее хранилище в 15 ГБ и на запросы (12 000/мин).
Ссылку на сборку можно сразу отправить клиенту.
Доступ команды должен быть только к телеграм-группе.
Этот велосипед просто едет 🚴‍♂.

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

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

GitHub Actions

GitHub Actions позволяет автоматизировать рабочие процессы непосредственно в репозитории GitHub. Поддерживает CI/CD и множество других задач.
Стоимость: Бесплатно для публичных репозиториев и ограниченного использования в частных репозиториях. Дополнительные минуты и пакеты начинаются от $4 за 1000 минут.

Bitrise

Bitrise — это платформа CI/CD, специально разработанная для мобильных приложений. Она предлагает интеграции с различными инструментами и сервисами.
Стоимость: Бесплатный план с ограниченными возможностями. Платные планы начинаются от $36 в месяц за команду.

CircleCI

CircleCI — это гибкий и мощный инструмент CI/CD, который поддерживает автоматизацию для мобильных приложений. Предлагает интеграции с различными сервисами и API.
Стоимость: Бесплатный план с ограниченными возможностями. Платные планы начинаются от $30 в месяц за 3 контейнера.

Fastlane

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

App Center by Microsoft

App Center предлагает полный набор инструментов для автоматизации CI/CD, тестирования и аналитики мобильных приложений.
Стоимость: Бесплатный план с ограниченными возможностями. Платные планы начинаются от $40 в месяц.

Jenkins

Jenkins — это один из самых популярных инструментов CI/CD с открытым исходным кодом, который можно настроить для автоматизации любых задач.
Стоимость: Бесплатно.

Travis CI

Travis CI — это облачный сервис CI/CD, который поддерживает множество языков программирования и интеграций с различными сервисами.
Стоимость: Бесплатный план с ограниченными возможностями. Платные планы начинаются от $69 в месяц.

Мы постоянно стремимся делать нашу работу лучше и эффективнее. Поэтому мы всегда ищем талантливых flutter-разработчиков и UX/UI-дизайнеров в нашу команду, чтобы вместе создавать красивые и простые решения. Особенно будем рады видеть таланты из Сибири, таких же, как и мы. Если вы хотите стать частью нашей команды, пожалуйста, свяжитесь с нами по e-mail: hr@adict.ru.

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

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

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

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

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

Настоящий CI/CD?

А что еще можно использовать?