Владислав Рябчевский

Flutter продолжает набирать популярность. Фреймворк предлагает низкий порог входа и возможность собрать приложение практически под любую платформу. Если вы хотите выпускать приложения стабильнее, чаще, быстрее, да еще и под несколько платформ и одним коммитом, то эта статья для вас. Зачем CI мобильному разработчику Flutter удобен в плане разработки. Просто напишите код на Dart — и вот у вас решение, которое можно запустить на устройствах под управлением Android и iOS. А можно собрать web-приложение или написать клиентское для десктопа (будь то Windows, Linux или MacOS). Но! Сборка под каждую платформу требует наличия SDK. Следовательно, для подготовки релиза под несколько платформ вам потребуется иметь несколько сред: Android SDK для Android-устройств, XCode builder для iOS, Platform SDK (+ специальная сборка Flutter) для «Авроры». Пока вы работаете один или небольшой группой, вы можете достаточно быстро собирать приложения под каждую платформу и направлять файлы в целевые маркеты. Однако по мере роста команды и зрелости продукта могут возникнуть перебои с поставками обновлений и их сборкой. Чтобы их избежать, можно несколько стандартизировать процесс и автоматизировать сборку приложений под все платформы. Один из инструментов для этого — CI-конвейер. Для создания пайплайна требуется специальный набор инструментов: платформа для запуска и контроля пайплайнов, а также набор агентов для выполнения сборки. Многие современные платформы для разработчиков уже включают в себя сразу систему контроля версий и инструментарий для настройки CI-процессов. И это те платформы, которыми вы, скорее всего, уже пользуетесь! Часть платформ для контроля версий и CI. Подготовка Когда вы выбрали удобную для команды или для себя платформу, необходимо выполнить пару простых шагов: скачать агент для CI и подключить его к проекту. Агенты поставляются с платформой, ссылка на их загрузку обычно есть в документации. Но где запускать этого агента? Один из вариантов — просто развернуть на локальном ПК. В самом начале это достаточно удобный вариант. Учтите, что иногда работать будет тяжело — запуск раннера «съедает» немало ресурсов. Следующий вариант — выделенный сервер. Это уже не бесплатно, но работает заметно стабильнее. За сервер отвечает провайдер IT-инфраструктуры, поэтому все вопросы по работе «железа» вы можете направить в техническую поддержку.Когда пайплайн отлажен и весь процесс настроен, можно посмотреть на облачных агентов, предоставляемых системами контроля версий. В таких агентах вы платите только за то время, что они функционируют. Однако если у вашей компании есть свои вычислительные мощности, вы можете смело запускать агента на них. Вы можете также сделать пайплайн в GitLab или Jenkins и создать для этого преднастроенный раннер. Для этого, кстати, в облаке Selectel можно выбрать образ с предустановленными инструментами. Каждая платформа имеет свои особенности при регистрации агентов, они описаны в соответствующих инструкциях для GitVerse, GitFlic, GitLab и GitHub. Когда выполнена настройка и привязка агента к проекту, можно приступать к написанию пайплайнов. CI для AOSP Первым рассмотрим пайплайн для сборки приложения под Android. Он достаточно простой и по своей сути повторяет действия, которые вы выполняете на ПК для сборки приложения локально. В первую очередь настроим JDK и SDK для сборки Android приложения. Установили? Тогда аналогичным образом добавляем Flutter. Код можно упростить, предварительно подготовив контейнер с нужным SDK. Так он и проще будет, и отрабатывать начнет быстрее. Также для ускорения работы контейнер с SDK предварительно можно загрузить на ПК/ВМ следующей командой: Дальше — выкачиваем исходные коды. Если код пайплайна создан в том же репозитории, что и исходный код проекта, удобно вызывать стандартный экшен checkout: Если же пайплайн находится отдельно (например, вы хотите собирать какую-то библиотеку для работы внутри вашего проекта), то можно использовать стандартные команды git: Для приватных репозиториев можно использовать токен самого раннера. Например, следующая конструкция достаточно удобно скачивает исходный код проекта. Его можно использовать на раннерах, где нет node.js: Дальше стандартный набор: скачивание зависимостей (pub get), запуск статического анализа (analyze) и тестирование (test). Для целей отладки пайплайна иногда полезно также добавить команду doctor — будет выполнена проверка окружения и переменных для работы Flutter. Все эти команды можно записать в одной джобе последовательно (даже в одну строку), но будет не очень удобно отлаживать. Разделение на отдельные джобы сразу подсветит, где именно возникла ошибка: О нет, у нас устаревшая библиотека! После проверок — сборка. Используя символ «|» (пайп, вертикальная черта) вы можете записать несколько команд для выполнения (как в bash-скрипте). Для примера выведем файлы в папке с релизом: Результат — собранное приложение. В недавнем релизе GitVerse добавили поддержку экшена для выгрузки артефактов. Давайте используем это при помощи следующего фрагмента кода: Параметр name отвечает за имя целевого архива, path — путь к файлу или папке с артефактом, retention-days — срок «свежести» артефакта. Последний параметр не рекомендуется завышать — быстро закончится место в вашем хранилище.Если все сделано правильно, то во вкладке CI/CD в разделе Артефакты появится собранное вами приложение: Полученный артефакт в виде APK-файла вы можете протестировать онлайн через сервис для тестирования мобильных приложений Selectel. Для этого перейдите в Панель управления → Мобильная ферма → Создать ферму. Выберете устройство из списка (доступны смартфоны на Android и iOS), тип тарификации и нажмите Создать ферму. Когда все заработает, перетащите APK-файл в интерфейс. Подождите пару минут и ваше приложение отобразится на экране устройства. Модернизируем под «Аврору» Пайплайн для «Авроры» не сильно отличается от пайплайна для Android или веб-приложения, а профит большой. Вы получаете готовое решение под отечественную платформу без значительных усилий. Самое заметное изменение — вместо команды flutter используется flutter-aurora. Если в проект ранее не добавлена платформа aurora, то нужно добавить ее. Помимо платформы дополнительно необходимо добавить несколько флагов: --templateapp — тип шаблона (app обычное приложение, также можно создавать библиотеки и пакеты); --orgru.aurora — имя организации, в соответствии с требованиями, участвует в формировании названия пакета. Следующие этапы аналогичны сборке Android-приложения и публикации артефакта: Полученное приложение для прохождения валидации и установки в «Аврору» должно быть подписано. Для этого действия можно использовать rpmsign из PlatformSDK: Для примера выполняется загрузка сертификата и ключа разработчика. Не делайте этого в продакшене. Подписанные приложения можно также опубликовать в качестве артефактов: Публикация артефактов Чтобы пользователи могли скачать актуальную версию, укажите им ссылку, где исполняются ваши пайплайны. Можно дать ее на нужный артефакт — это рабочий, но не самый удобный вариант. Лучше всего использовать вкладку Релизы.Релизы строятся от тега. Как назвать тег, решать вам. Обычно это номер версии приложения (или версия приложения и дополнительная информация). Чтобы добавить тег, необходимо на ПК переключиться на релизный коммит и ввести пару команд: Далее в выбранной платформе перейдите во вкладку Релизы и нажмите Новый релиз. Заполните основные поля и добавьте файлы с артефактами: Поздравляю, вы — DevOps! Как видите, ничего сложного в написании собственного пайплайна сборки приложения нет. При этом вы получаете удобный инструмент для нанесения пользы проекту. Не бойтесь экспериментировать: автоматизируйте публикацию в магазины, добавляйте дополнительные автотесты, создавайте пайплайны под разные ветки и с разными уровнями отладки, настройте уведомления в мессенджер и т. д. Основу для пайплайнов вы может брать из статьи или находить решения в open-source проектах и адаптировать под себя. Пример из этой статьи вы можете найти в репозитории.

Владислав Рябчевский

Материалы автора

Быстрый старт в CI на примере Flutter (под Android и «Аврору»)