Сборка и публикация приложений с помощью Codemagic CI/CD

Автор: | 29.04.2025
Нет комментариев
Post Views: 141

Введение

Разработка мобильных приложений состоит из нескольких частей, одними из которых являются сборка APK-файла (или AAB) и публикация его в магазинах приложений. И если для небольших приложений эти процессы могут занимать пару минут, то чем больше становится приложение, тем больше времени разработчики тратят на сборку. Даже использование различных средств для ускорения сборки и анализ проблемных участков не способны полностью решить эту проблему. И здесь на помощь приходят средства, позволяющие автоматизировать процессы сборки, тестирования и распространения кода, освобождая разработчика от рутинных задач и позволяя сосредоточиться непосредственно на написании кода.

Такой подход в разработке ПО называется CI/CD.

CI (Continious Integration) – термин, обозначающий частое обновление кода из разных источников и объединение его в один с последующими тестированием и сборкой.

CD (Continious Delivery) – термин, обозначающий подготовку протестированного и собранного кода к релизу и дальнейшему распространению.

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

Существует много различных сервисов, которые предоставляют услуги по автоматизации CI/CD, такие как Jenkins, Travis CI, CircleCI и другие. Многие платформы для хостинга репозиториев также реализуют свои собственные решения для CI/CD, поскольку система контроля версий тесно связана с данными процессами. Среди них можно выделить, например, GitHub Actions, GitLab CI/CD или Bitbucket Pipelines.

В этой статье мы рассмотрим один из таких сервисов под названием Codemagic и попробуем с его помощью автоматизировать сборку своего приложения.

Стоит заметить, что данный сервис работает не только для мобильных платформ, но и Web или Desktop.

Подготовка

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

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

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

Итак, мы добавили свой проект в Codemagic, на этом подготовка проекта завершена.

Настройка проекта

Если мы попробуем открыть созданный проект, то увидим ошибку, поскольку Codemagic не нашёл в репозитории файл конфигурации и не знает, что нужно сделать с приложением.

Для настройки Codemagic использует файл конфигурации YAML. В нём описываются все инструкции, которые будут выполняться для нашего приложения.

Создадим в корневой папке проекта файл codemagic.yaml. Сервис использует стандартный для YAML синтаксис, благодаря чему разработчикам будет проще ориентироваться, если ранее они уже работали с подобным. Этот файл нужно закоммитить в репозиторий, чтобы Codemagic смог его увидеть и использовать для конфигурации сборки.

Базовым элементом здесь является workflow. Именно в нём содержатся все операции, которые нужно выполнить для приложения. В файле можно прописать несколько workflow и при запуске сборки выбирать нужный.

workflows:
  first_workflow_name:
    ...
  second_workflow_name:
    ...

Напишем конфигурацию для сборки AAB-файла приложения, подписанного релизным ключом, и публикации его в Google Play, после чего разберём его по порядку.

workflows:
  native-android:
    name: Native Android
    max_build_duration: 60
    instance_type: mac_mini_m2
    environment:
      android_signing:
        - system_app_manager
      groups:
        - google_play
      vars:
        PACKAGE_NAME: "ru.androidtools.djvureaderdocviewer"
      java: 21
    scripts:
      - name: Set Android SDK location
        script: |
          echo "sdk.dir=$ANDROID_SDK_ROOT" > "$CM_BUILD_DIR/local.properties"
      - name: Build Android release
        script: |
          ./gradlew bundleGoogleRelease
    artifacts:
      - app/build/outputs/**/*.aab
    publishing:
      email:
        recipients:
          - <email>
        notify:
          success: true
          failure: true
      google_play:
        credentials: $GCLOUD_SERVICE_ACCOUNT_CREDENTIALS
        track: beta
        submit_as_draft: true

У workflow можно для удобства задать имя, которое будет отображаться в Codemagic во время работы с помощью name:.

Также мы ограничим максимальное время сборки 60 минутами через max_build_duration:, значение которого может быть от 1 до 120.

instance_type: указывает компьютер, на котором будет происходить сборка. В бесплатном тарифе доступен только Apple M2 Mac mini, для платных тарифов также доступны сборки на Windows и Linux.

Внутри environment: прописываются переменные среды, которые понадобятся нам во время сборки. В данном случае это ключ подписи приложения и учётные данные для доступа к Google Play API.

Остановимся на них поподробнее. Для того, чтобы Codemagic знал, чем подписывать наш AAB-файл, нужно загрузить ключ подписи. Для этого нужно перейти во вкладку Teams, выбрать аккаунт и найти раздел codemagic.yaml settings.

Здесь раскроем Code signing identities и выберем вкладку Android keystores. На ней нам нужно загрузить наш файл с хранилищем ключей, а также прописать пароль от хранилища ключей, alias ключа и пароль. Также нужно задать имя, по которому мы будем обращаться к этому хранилищу в файле конфигурации.

Если вернуться к нашей конфигурации, то в поле android_signing: можно увидеть system_app_manager – под этим именем и был сохранён ключ.

Codemagic возьмёт данные ключа и автоматически сгенерирует следующие переменные среды:

  • CM_KEYSTORE_PATH – путь до хранилища ключей
  • CM_KEYSTORE_PASSWORD – пароль от хранилища ключей
  • CM_KEY_ALIAS – имя ключа
  • CM_KEY_PASSWORD – пароль от ключа

Чтобы AAB подписался с помощью этих данных, нам нужно обновить build.gradle модуля app и добавить в него следующее:

val secretProperties = Properties().apply {
  if (System.getenv("CI").toBoolean()) { // задаём ключ из переменных среды
    setProperty("SIGNING_KEYSTORE_PATH", System.getenv("CM_KEYSTORE_PATH"))
    setProperty("SIGNING_KEYSTORE_PASSWORD", System.getenv("CM_KEYSTORE_PASSWORD"))
    setProperty("SIGNING_KEY_ALIAS", System.getenv("CM_KEY_ALIAS"))
    setProperty("SIGNING_KEY_PASSWORD", System.getenv("CM_KEY_PASSWORD"))
  } else if (keystoreProperties != null) { // задаём ключ из local.properties
    setProperty(
      "SIGNING_KEYSTORE_PATH",
      file(keysRepo + keystoreProperties["RELEASE_STORE_FILE"]).path
    )
    setProperty(
      "SIGNING_KEYSTORE_PASSWORD",
      keystoreProperties["RELEASE_STORE_PASS"].toString()
    )
    setProperty("SIGNING_KEY_ALIAS", keystoreProperties["RELEASE_ALIAS"].toString())
    setProperty("SIGNING_KEY_PASSWORD", keystoreProperties["RELEASE_KEY_PASS"].toString())
  }
}
val releaseSigning = signingConfigs.create("release") {
  storeFile = file(secretProperties["SIGNING_KEYSTORE_PATH"] as String)
  keyAlias = secretProperties["SIGNING_KEY_ALIAS"] as String
  storePassword = secretProperties["SIGNING_KEYSTORE_PASSWORD"] as String
  keyPassword = secretProperties["SIGNING_KEY_PASSWORD"] as String
}

buildTypes {
  release {
    isMinifyEnabled = true
    isShrinkResources = true
    proguardFiles(
      getDefaultProguardFile("proguard-android-optimize.txt"),
      "proguard-rules.pro"
    )
    signingConfig = releaseSigning
  }
}

Чтобы понимать, что сборка происходит на удалённой машине, в переменных среды также прописывается поле CI со значением true. По нему мы и будем определять, какие данные для ключа передать – из переменных среды или из локального источника.

Теперь нам нужно, чтобы Codemagic имел доступ к Google Play. Для этого нам нужно создать сервисный аккаунт в Google Cloud Platform, получить оттуда специальный JSON с учётными данными и загрузить в Codemagic. Подробно о том, как создать сервисный аккаунт, можно почитать здесь.

Как только JSON готов, нужно зайти в настройки проекта и перейти на вкладку Environment variables.

Здесь нужно создать новую переменную, имя для неё указываем GCLOUD_SERVICE_ACCOUNT_CREDENTIALS, а значение – содержимое нашего JSON. Также в variable group указываем google_play.

Также в поле vars: нужно указать идентификатор приложения. В нашем случае это ru.androidtools.djvureaderdocviewer.

Дополнительно в поле java: можно указать версию Java, для которой компилируется код.

Следующим важным полем является scripts:. В нём прописываются собственно команды, которые будут выполняться при сборке. В нашем случае достаточно двух команд:

  • Прописываем sdk.dir в local.properties
  • Запускаем сборку релизного AAB

Примечание: команда bundleRelease запускает сборку AAB, если вам нужен APK то воспользуйтесь командой assembleRelease.

Далее в поле artifacts: указываем нужные нам для работы артефакты. В данном случае это будет сгенерированный AAB или APK файл. Этот артефакт можно скачать из Codemagic для ручного тестирования или передать дальше на публикацию. В бесплатном тарифе артефакты хранятся на сервере в течение месяца.

Итак, если код не содержит ошибок и сборка прошла успешно, то мы можем перейти к дальнейшему распространению приложения.

В поле publishing: выбираем, куда мы хотим опубликовать приложение. Поскольку нам нужен Google Play, то и выбираем google_play:. Там мы указываем учётные данные сервисного аккаунта, сохранённые в переменной среде, а также ветку, в которую нужно опубликовать приложение.

Мы также можем подписаться на уведомления об успешной или неудачной публикации. Для этого в поле email: перечисляем адреса получателей, которые должны получиться уведомление, а также тип уведомления: успех или неудача.

Попробуем запустить сборку и посмотрим результат. Для примера возьмём одно из наших приложений DjVu Reader, в котором компилируются различные библиотеки C/C++ и проверим, сколько времени займёт сборка с публикацией.

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

Итак, сборка прошла успешно и весь процесс занял в сумме 5 минут 16 секунд, что весьма неплохо.

Из этого времени непосредственно на сборку AAB ушло 3 минуты 26 секунд, а на публикацию в Google Play 37 секунд.

Учитывая бесплатный лимит 500 минут в месяц, этого должно хватить примерно на 96 подобных сборок. Этого должно быть более чем достаточно для работы, если использовать сервис только для публикации релизных версий. Если же нужно ещё автоматизировать тестирование приложения, то здесь уже будет вероятность упереться в лимит.

Заключение

CI/CD является очень крайне полезным инструментом. Автоматизация различных процессов разработки положительно сказывается на остальных аспектах, позволяя сконцентрироваться на написании и улучшении кода.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *