От ручной работы к автоматизации: наш путь к идеальной доставке сборок 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?
Еще раз, мы можем настроить 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.
А на чем вы свой скрипт написали?
Привет! Python