Flutter продолжает набирать популярность. Фреймворк предлагает низкий порог входа и возможность собрать приложение практически под любую платформу. Если вы хотите выпускать приложения стабильнее, чаще, быстрее, да еще и под несколько платформ и одним коммитом, то эта статья для вас.

Зачем CI мобильному разработчику

Flutter удобен в плане разработки. Просто напишите код на Dart — и вот у вас решение, которое можно запустить на устройствах под управлением Android и iOS. А можно собрать web-приложение или написать клиентское для десктопа (будь то Windows, Linux или MacOS). Но! Сборка под каждую платформу требует наличия SDK. Следовательно, для подготовки релиза под несколько платформ вам потребуется иметь несколько сред: Android SDK для Android-устройств, XCode builder для iOS, Platform SDK (+ специальная сборка Flutter) для «Авроры». 

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

Мобильная ферма Selectel

Широкий парк устройств на Android и iOS, тестирование без ограничений и гибкий запуск.

Попробовать →

Для создания пайплайна требуется специальный набор инструментов: платформа для запуска и контроля пайплайнов, а также набор агентов для выполнения сборки. Многие современные платформы для разработчиков уже включают в себя сразу систему контроля версий и инструментарий для настройки CI-процессов. И это те платформы, которыми вы, скорее всего, уже пользуетесь!

Подготовка

Когда вы выбрали удобную для команды или для себя платформу, необходимо выполнить пару простых шагов: скачать агент для CI и подключить его к проекту. Агенты поставляются с платформой, ссылка на их загрузку обычно есть в документации. Но где запускать этого агента?

Один из вариантов — просто развернуть на локальном ПК. В самом начале это достаточно удобный вариант. Учтите, что иногда работать будет тяжело — запуск раннера «съедает» немало ресурсов.

Следующий вариант — выделенный сервер. Это уже не бесплатно, но работает заметно стабильнее. За сервер отвечает провайдер IT-инфраструктуры, поэтому все вопросы по работе «железа» вы можете направить в техническую поддержку.

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

Вы можете также сделать пайплайн в GitLab или Jenkins и создать для этого преднастроенный раннер. Для этого, кстати, в облаке Selectel можно выбрать образ с предустановленными инструментами.

Каждая платформа имеет свои особенности при регистрации агентов, они описаны в соответствующих инструкциях  для GitVerse, GitFlic, GitLab и GitHub. Когда выполнена настройка и привязка агента к проекту, можно приступать к написанию пайплайнов.

CI для AOSP

Пример работы приведен для GitVerse. Он практически точь-в-точь может быть запущен в GitHub. Для других платформ будет отличаться код, но логика в общем виде останется такой же.

Первым рассмотрим пайплайн для сборки приложения под Android. Он достаточно простой и по своей сути повторяет действия, которые вы выполняете на ПК для сборки приложения локально.

В первую очередь настроим JDK и SDK для сборки Android приложения. Установили? Тогда аналогичным образом добавляем Flutter.

jobs:
  build-android:
    name: Сборка android приложения
    runs-on: "ubuntu-latest" # Используется docker runner
steps:
  - name: Установка JDK
    uses: actions/setup-java@v3
    with:
      java-version: '17'
      distribution: 'temurin'
  - name: Установка Android SDK
    uses: android-actions/setup-android@v3
  - name: Добавляем flutter
    uses: subosito/flutter-action@v2
    with:
        flutter-version: "3.19.0"
        channel: "stable"

Код можно упростить, предварительно подготовив контейнер с нужным SDK. Так он и проще будет, и отрабатывать начнет быстрее. Также для ускорения работы контейнер с SDK предварительно можно загрузить на ПК/ВМ следующей командой:

docker pull androidsdk/android-30:latest

Дальше — выкачиваем исходные коды. Если код пайплайна создан в том же репозитории, что и исходный код проекта, удобно вызывать стандартный экшен checkout:

- name: Клонирование репозитория
  uses: actions/checkout@v4

Если же пайплайн находится отдельно (например, вы хотите собирать какую-то библиотеку для работы внутри вашего проекта), то можно использовать стандартные команды git:

- name: Клонирование стороннего репозитория (публичного)
  run: git clone https://github.com/kaboc/todo-with-grab.git .

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

- name: Клонирование репозитория (приватного)
  run: git clone https://${{ gitverse.token }}@gitverse.ru/${{ gitverse.repository }}.git .

Дальше стандартный набор: скачивание зависимостей (pub get), запуск статического анализа (analyze) и тестирование (test). Для целей отладки пайплайна иногда полезно также добавить команду doctor — будет выполнена проверка окружения и переменных для работы Flutter.

- name: Установка зависимостей
  run: flutter pub get
- name: Статический анализатор
  run: flutter analyze
- name: Тестирование приложения
  run: flutter test

Все эти команды можно записать в одной джобе последовательно (даже в одну строку), но будет не очень удобно отлаживать. Разделение на отдельные джобы сразу подсветит, где именно возникла ошибка:

После проверок — сборка. Используя символ «|» (пайп, вертикальная черта) вы можете записать несколько команд для выполнения (как в bash-скрипте). Для примера выведем файлы в папке с релизом: 

- name: Сборка приложения
  run: |
    flutter build apk --release
    ls -la build/app/outputs/apk/release/

Результат — собранное приложение. В недавнем релизе GitVerse добавили поддержку экшена для выгрузки артефактов. Давайте используем это при помощи следующего фрагмента кода:

- name: Загрузка APK в артефакты
  uses: actions/upload-artifact@v4
  with:
    name: android-apk
    path: build/app/outputs/apk/release/**/*.apk
    retention-days: 1

Параметр name отвечает за имя целевого архива, path — путь к файлу или папке с артефактом, retention-days — срок «свежести» артефакта. Последний параметр не рекомендуется завышать — быстро закончится место в вашем хранилище.

Если все сделано правильно, то во вкладке CI/CD в разделе Артефакты появится собранное вами приложение:

Полученный артефакт в виде APK-файла вы можете протестировать онлайн через сервис для тестирования мобильных приложений Selectel. Для этого перейдите в Панель управления → Мобильная ферма → Создать ферму. Выберете устройство из списка (доступны смартфоны на Android и iOS), тип тарификации и нажмите Создать ферму.

Когда все заработает, перетащите APK-файл в интерфейс. Подождите пару минут и ваше приложение отобразится на экране устройства.

Модернизируем под «Аврору»

Для сборки вам понадобится использовать shell-раннер, преднастроенный PlatformSDK и Flutter, установленный по инструкции. Рекомендую вместо алиасов добавить папку с исполняемыми файлами flutter-aurora в PATH.

Пайплайн для «Авроры» не сильно отличается от пайплайна для Android или веб-приложения, а профит большой. Вы получаете готовое решение под отечественную платформу без значительных усилий. Самое заметное изменение — вместо команды flutter используется flutter-aurora.

Если в проект ранее не добавлена платформа aurora, то нужно добавить ее. Помимо платформы дополнительно необходимо добавить несколько флагов:

• --template=app — тип шаблона (app = обычное приложение, также можно создавать библиотеки и пакеты);

• --org=ru.aurora — имя организации, в соответствии с требованиями, участвует в формировании названия пакета.

- name: Добавляем платформу Аврора ОС
  run: |
    flutter-aurora create --platforms=aurora --template=app --org=ru.aurora .
    rm test/widget_test.dart

При добавлении платформы Flutter автоматически добавляет файл test/widget_test.dart, если его в проекте нет. Однако этот файл не содержит корректных тестов для вашего приложения и может сгенерировать исключение на этапе анализа.

Следующие этапы аналогичны сборке Android-приложения и публикации артефакта:

- name: Установка зависимостей
  run: flutter-aurora pub get
- name: Статический анализатор
  run: flutter-aurora analyze --no-fatal-infos
- name: Тестирование приложения
  run: flutter test
- name: Сборка приложения
  run: |
    flutter-aurora build aurora --release
    ls -la $(find build -name "*.rpm")

Анализатор иногда может выдавать информационные сообщения, по типу «эта библиотека устарела, будьте осторожны при ее использовании». По умолчанию такое исключение возвращает в Linux сигнал ошибки выполнения и пайплайн падает. Чтобы этого не происходило, можно добавить флаг --no-fatal-infos.

Полученное приложение для прохождения валидации и установки в «Аврору» должно быть подписано. Для этого действия можно использовать rpmsign из PlatformSDK:

- name: Подпись пакета
  run: |
    curl -O https://developer.auroraos.ru/content-images/dev-doc/{regular_key.pem,regular_cert.pem} -A "Mozilla/5.0"
    psdk-chroot rpmsign-external sign --key regular_key.pem --cert regular_cert.pem *.rpm

Для примера выполняется загрузка сертификата и ключа разработчика. Не делайте этого в продакшене.

Подписанные приложения можно также опубликовать в качестве артефактов: 

     - name: Загрузка APK в артефакты
       uses: actions/upload-artifact@v3
       with:
         name: aurora-rpm
         path: ./build/aurora/psdk_5.1.3.85/aurora-arm/release/RPMS
         retention-days: 1

Публикация артефактов

Чтобы пользователи могли скачать актуальную версию, укажите им ссылку, где исполняются ваши пайплайны. Можно дать ее на нужный артефакт — это рабочий, но не самый удобный вариант. Лучше всего использовать вкладку Релизы.

Релизы строятся от тега. Как назвать тег, решать вам. Обычно это номер версии приложения (или версия приложения и дополнительная информация). Чтобы добавить тег, необходимо на ПК переключиться на релизный коммит и ввести пару команд:

git tag -a 0.0.1 -m "комментарий"
git push origin --tags

Далее в выбранной платформе перейдите во вкладку Релизы и нажмите Новый релиз. Заполните основные поля и добавьте файлы с артефактами:

Поздравляю, вы — DevOps!

Как видите, ничего сложного в написании собственного пайплайна сборки приложения нет. При этом вы получаете удобный инструмент для нанесения пользы проекту.

Не бойтесь экспериментировать:

• автоматизируйте публикацию в магазины,

• добавляйте дополнительные автотесты,

• создавайте пайплайны под разные ветки и с разными уровнями отладки,

• настройте уведомления в мессенджер и т. д.

Основу для пайплайнов вы может брать из статьи или находить решения в open-source проектах и адаптировать под себя. Пример из этой статьи вы можете найти в репозитории.