Автоматизируйте трудоемкие задачи Android, такие как создание и распространение вашего приложения.

Как следует из названия, эта статья посвящена автоматизации рабочего процесса разработки Android с помощью fastlane.

Вы можете подумать: «Но ... автоматизация - это нечто общее и применимо практически ко всему, о чем вы можете подумать, особенно при создании программного обеспечения. Так ты можешь быть точнее? "

На самом деле я имею в виду следующее:

  • Используйте варианты сборки, чтобы указать, работает ли ваше приложение на тестовых или производственных конечных точках.
  • Назначьте конфигурацию подписи для каждого варианта
  • Автоматизация управления версиями с помощью схемы и инструментов управления версиями
  • Используйте fastlane для запуска тестов; создавать и распространять наше приложение через Firebase App Distribution

К сожалению, последняя часть будет доступна только для пользователей Mac OS и Unix только из-за того, что fastlane еще официально не поддерживает ОС Windows.

Варианты сборки

Варианты сборки - это мощная функция Android, которая позволяет нам иметь разные конфигурации для наших сборок. Варианты сборки состоят из типов сборки в сочетании с ароматизаторами. Я предлагаю прочитать больше о вариантах сборки, если вы еще этого не сделали.

Мой опыт работы с Android показал мне, что для оптимизированной среды разработки вам потребуется как минимум четыре варианта сборки, если иное не указано в бизнесе, например, версии премиум и бесплатная версия приложения. Мы собираемся использовать следующие варианты сборки:

  • developmentDebug: Для повседневного развития
  • productionDebug: Для крайних (или не очень) случаев, когда нам нужно проверить наличие ошибки в производственных данных
  • developmentRelease: Этот вариант будет распространен среди нашей команды QA через Firebase Crashlytics. Это будет копия нашей версии для Play Маркета, кроме того, что она будет использовать наши тестовые серверы.
  • productionRelease: версия для Play Маркета

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

Типы сборки

Когда мы создаем новый проект Android, по умолчанию мы получаем два типа сборки: debug и release . Если вы проверите свой модуль приложения build.grade, отладка будет опущена.

Но если вы проверите варианты сборки, которые можно найти в разделе «Просмотр»> «Окна инструментов», и выберите раскрывающийся список «Вариант активной сборки», вы увидите два варианта. Android по умолчанию предоставляет тип сборки debug.

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

В строке 4 мы также указали applicationIdSuffix. Таким образом, наша debug сборка будет иметь суффикс .debug, что означает, что если идентификатор нашего приложения, например, com.example.myapp, отладочная сборка будет com.example.myapp.debug.

Создавайте ароматы

Варианты сборки (необязательно) являются братьями и сестрами для типов сборки. Мы будем использовать две разновидности, отражающие наши серверы: development и production. Итак, вернитесь к Gradle сборки вашего приложения и добавьте следующее перед блоком buildTypes (здесь важен порядок), который мы добавили ранее.

В строке 1 мы определяем новое измерение, server, и оно используется как измерение наших development и production вкусов. Мы также определяем applicationIdSuffix для ароматов.

Затем выполните синхронизацию Gradle и снова проверьте варианты сборки. Вы должны выглядеть примерно так:

Название приложения

Теперь, когда у нас есть набор вариантов сборки, было бы удобно, если бы у нас было немного другое имя для каждого варианта. Так что продолжайте и добавьте три новых файла строковых ресурсов (щелкните правой кнопкой мыши ›New› Android Resource File), по одному для каждого дополнительного варианта. Мы будем использовать основной исходный набор для нашего productionRelease варианта. Вы выбираете вариант из раскрывающегося списка Исходный набор в представленном диалоговом окне, как показано ниже:

Эта операция создаст соответствующий исходный набор и добавит вновь созданные strings.xml в каждый из них.

Конфигурация подписи

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

Предупреждение. Не добавляйте эти файлы в свой Git, особенно если вы решите сохранить сертификат Play Store.

Нам нужно только подписать наш releaseDevelopment вариант, который будет доставлен нашей группе тестирования через Firebase App Distribution. Теперь, как и в части управления версиями, нам нужна функция для анализа свойств подписи в этих файлах.

Чтобы использовать this, нам нужно определить новую конфигурацию подписи. По-прежнему в вашем файле Gradle, внутри блока Android, добавьте следующий блок signingConfigs.

Наконец, обновите тип сборки выпуска следующим образом:

В строке 4 мы явно устанавливаем конфигурацию подписи Frebase, которая будет использоваться для варианта developmentRelease.

Управление версиями

Управление версиями Android действительно простое, но совсем не автоматизированное. Чтобы обновить versionCode и versionName, вам нужно отредактировать build.gradle своего приложения и установить желаемые значения. Тот факт, что эту задачу должен выполнять человек снова и снова, делает ее подверженной ошибкам. В данном примере используется схема управления версиями major.minor.patch для имени версии и номер инкрементной сборки для кода версии.

Откройте файл Gradle сборки и добавьте следующие функции под блоком зависимостей:

Короче говоря, readVersion попытается открыть файл version.properties, расположенный в корневом каталоге, и прочитать основные, второстепенные, исправления и свойства кода, которые будут в нем. Если файл не существует или свойства отсутствуют, по умолчанию используется значение major = 1, minor = 0, patch = 0 и code = 1. Результат readVersion используется в readVersionName и readVersionCode.

Теперь продолжайте и обновите свойства versionCode и versionName. В конфигурации по умолчанию замените их значения на следующие:

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

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

Открытие терминала и ввод ./gradlew doBuildNumberIncrement вызовет выполнение последней задачи, которая, в свою очередь, вызовет incrementBuildVersion. Переключитесь в Project View, и вы увидите только что созданный файл.

Тестирование, сборка и распространение

скоростная трасса

fastlane - это инструмент автоматизации с открытым исходным кодом, который, как говорится на его веб-сайте, «выполняет утомительные задачи, так что вам не нужно». Поскольку он изначально разрабатывался для автоматизации нескольких задач в приложениях iOS и Mac OS, fastlane имеет базовую функциональность для Android. В качестве компенсации за это тот факт, что его API открыт, и вы можете писать свой собственный код.

Есть несколько способов установить fastlane - я выберу универсальный. fastlane - это драгоценный камень (это означает, что он написан на Ruby, поэтому Ruby - ваша единственная зависимость). Итак, откройте тип терминала sudo gem install fastlane -NV и нажмите Enter. Чтобы проверить, все ли в порядке с вашей установкой, введите fastlane — version, и вы должны увидеть путь к исполняемому файлу и версию.

Наконец, нам нужно инициализировать fastlane для нашего проекта. Для этого все, что вам нужно сделать, это cd to/your/project/directory, ввести fastlane init и нажать Enter. Fastlane задаст вам несколько вопросов - вы можете пропустить их все. Мы напишем собственные дорожки.

Распространение приложений Firebase

Но прежде чем писать собственные дорожки, есть еще кое-что. Собственно два. Первый - это интерфейс командной строки Firebase, который можно установить, набрав curl -sL https://firebase.tools | bash и введя его в свой терминал.

Затем нам нужно установить плагин Firebase, поэтому перейдите в каталог вашего проекта, введите fastlane add_plugin firebase_app_distribution и нажмите Enter.

По-прежнему в терминале введите firebase login. Откроется браузер по умолчанию, и вам потребуется войти в свою учетную запись. Мы почти там.

Помимо входа в систему у вас должен быть проект и ваше приложение, настроенные в консоли Firebase. Если вы еще этого не сделали, сейчас хорошее время. Этот идентификатор приложения понадобится нам на этапе распространения.

Для сборок CI / CD вы должны использовать firebase login:ci, который вернет токен обновления, который вы позже сможете использовать в firebase_app_distribution action.

Тестируйте, создавайте и распространяйте

Наконец-то мы там. Давайте напишем нашу дорожку и распространим наше приложение. Откройте Fastfile и замените его содержимое следующим образом:

Теперь позвольте мне немного рассказать о том, что мы создали. Начните с открытия терминала в каталоге вашего проекта и ввода fastlane lanes. Вы должны увидеть что-то вроде следующего:

--------- android---------
----- fastlane android test
Runs all the tests
----- fastlane android firebase
Submit a new build to firebase app distribution
Usage:
fastlane firebase
Params:
versionChange:"minor|major|patch" to explicitly increase version
notes:"Release notes about the build"
branch:"branch_name" If specified will commit version.properties file and push it to track remote branch

Я выделил две части, которые нас интересуют. Это наши две полосы, первая из которых является полосой для запуска наших тестов. Если мы введем fastlane test, мы увидим, что наше приложение создается, и наши тесты в конечном итоге будут запущены.

Если наши тесты выполняются без ошибок, мы получаем сообщение fastlane.tools finished successfully 🎉, и все готово. В редких случаях, когда наши тесты терпят неудачу, мы получаем хороший результат, указывающий на неудачный тест, в дополнение ко многим другим журналам, как показано ниже.

com.max.hackernews.ExampleUnitTest > addition_isCorrect FAILED
    java.lang.AssertionError at ExampleUnitTest.kt:15
1 test completed, 1 failed

Последний переулок, Firebase, - совсем другая история. Разбивая его шаг за шагом, мы замечаем, что на первом этапе мы увеличиваем номер сборки в строках 37-45, используя задачу, которую мы определили в части управления версиями. Если параметр versionName предоставлен с любым из второстепенных, основных значений или значений исправления, то вместо этого изменится эквивалентная часть схемы управления версиями.

После обновления версии строки 47-51 содержат этап сборки. Здесь мы указываем тип сборки и вкус, который мы будем создавать, и вызываем задачу сборки. Выходной файл .apk можно найти в каталоге app/build/outputs/development/release.

Строка 53 заботится о наших примечаниях к выпуску о сборке, которые дойдут до нашей группы контроля качества. Если указан параметр примечаний, это будет сообщение примечаний к выпуску; в противном случае он возвращается к нашей последней фиксации.

У нас есть артефакты сборки и примечания к выпуску. Осталось загрузить все это в Firebase. И это то, что мы делаем в строках 55–59.

В первой части дорожки мы увеличиваем номер нашей версии; поэтому мы модифицируем version.properties. Строки 61–68, автоматизируют синхронизацию с удаленной ветвью, если указано имя ветки.

Резюме

Несмотря на то, что известно, что наличие инструмента CI / CD, такого как Jenkins для выполнения этих задач, является идеальным сценарием, запуск этого конвейера локально удовлетворительно выполнит эту работу. Когда вы получите эту инфраструктуру CI / CD, вы сможете мгновенно объединить ее с этим конвейером.

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