Автоматизация разработки для Android с помощью GitHub Actions

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

Если вы когда-нибудь разрабатывали приложение для Android, то знаете, насколько утомительными могут быть некоторые задачи:

• Выполнение тестов

• Убедиться, что приложение компилируется при добавлении нового кода

• Сборка и публикация приложения.

Но кому мы передадим эти задачи? Другому коллеге? Он может перепоручить их кому-то еще, и это не освободит время ни для кого. К тому же, мы не хотим расстраивать наших коллег. Решение?

Поприветствуйте GitHub Actions.

Что такое GitHub Actions?

GitHub Actions - это команды, которые мы можем запускать, когда что-то происходит в нашем репозитории. По своей сути, действие (action) - это конфигурационный файл, содержащий список команд, которые описывают:

• Когда это должно произойти

• Что должно произойти

Этот конфигурационный файл имеет формат YAML (.yml), и пример выглядит следующим образом. Пример GitHub Action:

name: My GitHub Action

on: pull_request

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1

Давайте разберем приведенный выше пример:

1. Даем имя нашему действию (My GitHub Action) [Необязательно]

2. Указываем, когда это действие должно выполняться (когда открыт пул-реквест).

3. Начинаем список задач (jobs), которые должны произойти после запуска этого действия.

4. Первое из них - это действие по сборке.

5. Команда runs-on указывает GitHub, какой runner будет выполнять это задание (это виртуальный сервер, и вы можете выбрать между Windows/Mac/Linux).

6. Каждое задание может иметь множество фаз, которые группируются вместе с помощью ключевого слова steps.

7. Ключевое слово uses указывает скрипту, какое действие следует предпринять.

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

Все файлы GitHub Actions должны находиться в основной папке вашего проекта по пути .github/workflows

Действия для пул-реквестов

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

1. Установка версии JDK

2. Изменение разрешений для виртуальной среды

3. Запуск тестов (если они у нас есть)

4. Сборка приложения

name: Android Build

on: pull_request

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1

      - name: Set Up JDK              // 1
        uses: actions/setup-java@v1
        with:
          java-version: 1.8

      - name: Change wrapper permissions  // 2
        run: chmod +x ./gradlew

      - name: Run Tests                   // 3
        run: ./gradlew test

      - name: Build Project               // 4
        run: ./gradlew assemble

1. Установка версии JDK

2. Изменение разрешений для виртуальной среды

3. Запуск тестов (если они у нас есть)

4. Сборка приложения

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

Второй шаг необходим для того, чтобы виртуальная среда могла выполнять команды gradle. Без него у нее не получится этого сделать.

Действия для публикации приложения

После того как вы впервые опубликовали свое приложение, его повторная публикация становится чем-то вроде рутины. Убедиться, что версия обновлена, создать apk, отправить его через Google Play Console и другие утомительные задачи. Можно автоматизировать этот процесс с помощью другого действия GitHub Action. Оно немного сложнее, чем предыдущее, поскольку требует использования GitHub Secrets. В двух словах, GitHub Secrets - это способ хранения конфиденциальной информации в качестве переменных окружения вашего репозитория. Нам придется использовать это, потому что:

1. Нужно будет подписать наше приложение

2. Необходимо дать этому действию разрешение на отправку нашего приложения в Google Play Store.

Давайте сначала выясним, как мы можем создать GitHub Secrets.

• На главной странице вашего репозитория перейдите на вкладку Settings (Настройки)

• В левом боковом меню будет название опции Secrets (Секреты).

• Чтобы создать секрет, нажмите кнопку New repository secret (Новый секрет репозитория).

Теперь, когда мы разобрались с этим, давайте рассмотрим сценарий для публикации приложения:

name: Android Publish

on:
  workflow_dispatch:

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1

      - name: Set Up JDK
        uses: actions/setup-java@v1
        with:
          java-version: 1.8

      - name: Change wrapper permissions
        run: chmod +x ./gradlew

      - name: Run Tests
        run: ./gradlew test

      - name: Build Project
        run: ./gradlew build

      - name: Build Release AAB      // 1
        run: ./gradlew bundleRelease

      - name: Sign AAB               // 2
        uses: r0adkll/sign-android-release@v1
        with:
          releaseDirectory: app/build/outputs/bundle/release
          signingKeyBase64: ${{ secrets.SIGN_KEY }}
          alias: ${{ secrets.ALIAS }}
          keyStorePassword: ${{ secrets.STORE_KEY_PASSWORD }}
          keyPassword: ${{ secrets.KEY_PASSWORD }}

      - name: Deploy to Play Store   // 3
        uses: r0adkll/upload-google-play@v1
        with:
          serviceAccountJsonPlainText: ${{secrets.SERVICE_ACCOUNT}}
          packageName: com.tomerpacific.laundry
          releaseFiles: app/build/outputs/bundle/release/app-release.aab
          track: production

Возможно, вы заметили, что данное действие будет выполняться на workflow_dispatch. Что это значит? По сути, он позволяет запускать действие вручную из самого GitHub. Вполне очевидно, вы можете решить, что лучше запускать это действие, когда в основной ветке происходит push (например).

Шаг, отмеченный цифрой 1 в приведенном выше фрагменте, запускает создание .aab нашего приложения. Затем, как и в случае создания приложения в Android Studio, необходимо подписать этот .aab-файл. Здесь впервые в игру вступают GitHub Secrets. Нужно создать секреты для:

• Ключа подписи (secrets.SIGN_KEY)

• Псевдоним ключа (secrets.ALIAS)

• Пароль ключа хранения (secrets.STORE_KEY_PASSWORD)

• Пароль ключа (secrets.KEY_PASSWORD)

После подписания файла .aab можно развернуть его в Google Play Store. На этом этапе предстоит еще немного поработать, поскольку нужно предоставить этому действию GitHub разрешение на развертывание приложений для нас в Google Play. Но как же это сделать? Мы используем Service Account.

Создание Service Account

Service Account (Учетная запись службы) - это созданная вами сущность, которая сообщает службам или приложениям, с которыми она взаимодействует, что она работает от вашего имени.

В данном случае GitHub Action будет взаимодействовать с Google Play Store, чтобы он мог загрузить новую версию нашего приложения. Для создания учетной записи службы перейдите в Google Cloud Console. Если у вас нет учетной записи, обязательно создайте ее. Затем на главной странице в левом боковом меню появится пункт списка под названием Service Accounts.

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

В открывшемся окне необходимо ввести название службы, а также ее описание.

Имя, указанное здесь, будет уникальным идентификатором этой учетной записи службы. На втором этапе вам будет предложено назначить этой учетной записи службы роль. Из выпадающего списка “Select A Role (Выбрать роль)" выберите Basic → Editor (Базовый → Редактор).

Наконец, на третьем шаге заполните свой email в обоих местах в разделе "Granting users access to this service account (Предоставление пользователям доступа к этой учетной записи службы)".

После нажатия кнопки "Done (Готово)" вам нужно будет создать ключ для этой учетной записи службы. Этот ключ будет использоваться нашим действием для идентификации в Google Play. Для этого кликните по трем горизонтальным точкам под надписью "Actions (Действия)" на главном экране учетной записи службы. В появившемся меню выберите пункт "Управление ключами (Manage keys)".

В этом окне мы создадим ключ, нажав кнопку New Key (Новый ключ) и выбрав в появившемся меню пункт create new key (создать новый ключ).

Теперь у нас есть возможность выбрать формат нашего нового ключа, по умолчанию это JSON, его и оставим.

После этого на ваш компьютер будет загружен файл. Обязательно сохраните его, так как в нем содержатся все данные, относящиеся к вашей учетной записи сервиса, и повторно загрузить его вы уже не сможете. Возьмем содержимое этого файла и создадим с его помощью секрет GitHub (secrets.SERVICE_ACCOUNT).

И последнее, но не менее важное: нужно сделать так, чтобы Google Play узнал об этом сервисном аккаунте. Для этого потребуется войти в наш аккаунт Google Play Console и перейти к разделу Setup →API Access (Настройка → Доступ к API). Если вы прокрутите открывшуюся страницу вниз, то обнаружите раздел под названием “Service Accounts (Учетные записи служб)”. Вы должны увидеть аккаунт службы, который был создан ранее. Кликните ссылку “Grant Access (Предоставить доступ)”.

В открывшихся настройках перейдите к разделу "App permissions (Разрешения приложений)". В нем выберите, с какими приложениями взаимодействует эта учетная запись службы. Там, в подразделе "Account permissions (Разрешения учетной записи)", все пункты в списке "releases (выпуски)" должны быть отмечены галочками. Я очень советую вам посмотреть все остальные настройки и решить для себя, что вы хотите оставить отмеченным, а что убрать. Как только закончите, кликните на кнопку "Invite user (Пригласить пользователя)", расположенную в правом нижнем углу.

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

Мониторинг наших действий в GitHub

Чтобы посмотреть, какие действия определены для вашего репозитория, перейдите на вкладку Actions. На этой вкладке отображаются все определенные рабочие процессы и те, которые уже были запущены.

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

Если действие определено для запуска на workflow_dispatch, вы увидите кнопку, позволяющую запустить его (как на рисунке выше). Чтобы увидеть запуск конкретного рабочего процесса, можно также сделать это на главной странице рабочих процессов, кликнув на одном из них. Если одно из действий не запускается, то здесь следует разобраться, что пошло не так. Наше первое действие должно запускаться при открытии пул-реквеста. Если оно работает правильно, должно появиться следующее:

.       .       .

Чтение было долгим, но мы рассмотрели все, что нужно чтобы начать создание пайплайнов Continuous Integration и Continuous Deployment (CI/CD) для ваших приложений. Если вам интересно посмотреть, как устроены GitHub Actions, то можете проверить их в одном из моих репозиториев здесь.

Чтобы узнать больше о GitHub Actions, перейдите по ссылке.

Материал подготовлен в рамках курса «Android Developer. Professional». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.