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

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

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

Вынесем за скобки более сложные процессы доставки сборок через полноценные 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.

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

Все просто! ?

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

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

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