GitHub Actions как CI/CD для mobile-проектов

Kate

Administrator
Команда форума
Меня зовут Валерий Кузнецов и я работаю Senior Android Engineerом в ThredUP. Хочу рассказать почему и как мы переезжали с Jenkins на GitHub Actions в качестве CI/CD системы для Android-приложения и как мы сделали автоматизацию, которая экономит нам время и силы на проверку и релиз наших приложений.

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

Наше приложение развивалось, команда расширялась, и мы стали планировать большое количество улучшений и автоматизации наших рабочих процессов: от проверки кода до релиза в продакшен. Исторически сложилось, что сборка нашего Android-приложения была настроена на Jenkins и работала на self-hosted машинах, но из-за ограничений внешних ресурсов для обновления машин, Jenkins-версий, билд-скриптов, мы решили посмотреть на облачные альтернативы. Как раз в тот момент GitHub выпустил продукт под названием GitHub Actions в Beta-доступ.

Почему GitHub Actions?​

На тот момент уже было довольно много других облачных альтернатив CI/CD ч (Bitrise, CircleCI, Travis), даже с фокусом на мобильную разработку, но GitHub Actions показался нам привлекательным по двум простым причинам:

  1. В Enterprise-план GitHub уже включено 50,000 минут. Никаких дополнительных оплат или согласований не надо.
  2. Actions являются частью большой GitHub-экосистемы, что несет за собой дополнительные преимущества в виде защищенности, поддержки, открытости исходного кода для некоторых частей системы.

Компоненты​

Github Actions работает, используя следующие основные компоненты:

  • Workflows — самый высокоуровневый компонент, содержащий всю необходимую информацию о работе, которую нужны выполнить (и после каких событий).
  • Events — это конкретное событие, запускающее workflow. Например, создание pull request, issue в репозитории, git push в конкретную ветку репозитория или же веб-хук, вызванный сторонним сервисом.
  • Jobs — это набор шагов, которые выполняться на одной билд-машине.
  • Steps — исполняемая часть в рамках Job. В качестве исполняемого шага может быть actions или простой сценарий командной строки. Все шаги внутри одной Job выполняются в рамках одной билд-машины, и это позволяет им обмениваться данными друг с другом.
  • Actions — это самый маленький исполнимый и переиспользуемый блок workflow.
blobid0_nQswmCQ.png
Иерархия компонентов

WorkFlows​

Для того, чтобы начать работу GitHub Actions, требуется создать файл workflow в формате .yml или .yaml в папке проекта .github/workflows/. В этих файлах содержаться все настройки и шаги, необходимые для выполнения автоматизации. Workflow можно использовать для сборки, тестирования, релиза ваших проектов, а также любых других автоматизаций работы, связанных проектом на GitHub (например, при создании issue автоматически ответить каким-то шаблоном). Вот простой пример того, как может выглядеть workflow для сборки Android-приложения:

image_50915873351635866262385.png


Actions​

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

Редактор​

WorkFlow в GitHub Actions используют YAML в качества основного языка для конфигураций. Есть веб-редактор с поддержкой подсказок для автозаполнения.

Все workflow хранятся .github/workflows-папке в репозитории проекта, что удобно с точки зрения контроля-версий, но и создает некоторые трудности, когда надо обновить файл workflow во всех актуальных ветках.

image_99603236841635866262384.gif
Гиф редактора с примером автозаполнения

Также есть неофициальный VS-плагин для работы с GitHub Actions.

Наш WorkFlow​

Исходный код WorkFlow для сборки на каждый Pull Request:

name: PR
on:
push:
branches: [ dev ]
pull_request:
branches: [ '**' ]
jobs:
build:
runs-on: ubuntu-18.04
steps:
- uses: actions/checkout@v2
- uses: actions/setup-go@v2
with:
go-version: '^1.14.7'
- run: go version
- name: Set up JDK 11
uses: actions/setup-java@v1
with:
java-version: '11'
- uses: ruby/setup-ruby@v1
with:
ruby-version: 2.7.1
- name: Install Dependencies
run: gem install bundler && bundle install
- uses: reviewdog/action-setup@v1
with:
reviewdog_version: latest
- name: Build with Fastlane
run: fastlane dev
- name: Run reviewdog
if: ${{ failure() }}
continue-on-error: true
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: reviewdog -f=checkstyle -name="ktlint" -reporter=github-pr-review < thredUP/build/reports/ktlint/ktlintMainSourceSetCheck/ktlintMainSourceSetCheck.xml

WorkFlow состоит из следующих частей:

  • Name — название WorkFlow для отображения в истории, может отличаться от названия файла worfklow.
  • On — события, при которых запускается данный workflow. В нашем случае — это push кода в git dev ветку и push кода для созданных pull requests в любую git-ветку проекта.
  • Jobs — список задач на выполнение. В нашем случае — всего одна задача build, состоящая из:
    • Выбор виртуальной машины на которой будет происходить сборка проекта. Мы для сборки Android-проектов сейчас используем образ ubuntu-18.04. Нам нет необходимости собирать Android-проект на macOS, и Linux VM потребляют минуты без дополнительного коэффициента.
    • runs-on: ubuntu-18.04
  • Настройки окружения для сборки проекта:
steps:
- uses: actions/checkout@v2
- uses: actions/setup-go@v2
with:
go-version: '^1.14.7'
- run: go version
- name: Set up JDK 11
uses: actions/setup-java@v1
with:
java-version: '11'
- uses: ruby/setup-ruby@v1
with:
ruby-version: 2.7.1
- name: Install Dependencies
run: gem install bundler && bundle install
- uses: reviewdog/action-setup@v1
with:
reviewdog_version: latest

  • Запуск сборки проекта с помощью Fastlane.
- name: Build with Fastlane
run: fastlane dev

  • В случае ошибки сборки проекта запускаем ReviewDog для того, чтобы отправить ошибки, связанные со стилем кода в качестве комментариев на Pull Request.
- name: Run reviewdog
if: ${{ failure() }}
continue-on-error: true
env:
REVIEWDOG_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: reviewdog -f=checkstyle -name="ktlint" -reporter=github-pr-review < thredUP/build/reports/ktlint/ktlintMainSourceSetCheck/ktlintMainSourceSetCheck.xml

Почему Fastlane​

Несмотря на то что GitHub Actions уже могут полностью заменить все, что у нас используется в рамках Fastlane для сборки проекта, запуска тестов и деплоя на Google Play, мы остались на нем по следующим причинам:

  • При первой настройке CI/CD на GitHub Actions они были еще в Beta-статусе и не хотелось тратить рерурсы по настройке CI впустую, поэтому решили использовать Fastlane: его скрипты можно было бы переиспользовать в рамках любого облачного CI, который поддерживает Ruby.
  • Fastlane по личным ощущениям все еще более ориентирован полностью на мобильную платформу, и новые скрипты ориентированные именно на Android/iOS. Их обновления выходят чаще в рамках Fastlane, чем GitHub Actions.

GitHub Community​

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

Виртуальные машины​

GitHub Actions работает на базе вирутальных окружений и предоставляет следующие готовые окружения:

image_36736044161635866262386.png


GitHub Actions использует Standard_DS2_v2 машины с 2 vCPU и 7 Гб оперативной памяти в рамках Microsoft Azure. Также есть возможность собрать свое окружение и запускать workflow в рамках собственных локальных машин, подключаемых к GitHub Actions с целью кастомизации программного обеспечения и оборудования.

Стоимость​

image_11073403031635866262299.png
Источник: github.com/features/actions

Нам вполне хватает 50 000 минут работы на Linux-машинах, но в случае, если захотим подключить Windows или macOS-машины, то минуты начнут потребляться с повышенным коэффициентом — x2 за Windows, x10 за macOS.

Мы проводили базовое сравнение с альтернативой, которую рассматривали, — Bitrise, и аналогичное количество минут (50 000) на Linux-билд машинах стоило бы нам порядка $1755 в месяц со всеми скидками.

Значок статуса​

Также можно добавить значок статуса выполнения автоматизации, если открыть детали workflow -> настройки -> создать значок статуса.

ZCeJDY58Zp6j7mqEA_LwoIAAldB7KUjtHZ_FKgf7XXRg7o4T3Ftnv3jaaBKJF3OUbCCL7CSPolMeRXPP0g1wp_0dXioUkbJ2iEw69gCBpBbRzkWPmLvQEkPmSg7Q56cXtrolydyW


Заключение​

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

Плюсы​

  • Довольно простая первичная настройка за счет интеграции с GitHub-экосистемой, хорошей документацией и возможности просмотреть workflow проектов с открытым исходным кодом.
  • Большое и постоянно растущее количество actions с открытым кодом, покрывающее совершенно различные сценарии использования. На момент написания статьи их 10334.
  • Версионирование workflow, так как они являются частью git-репозитория и помогают с откатом настроек. Есть возможность иметь разные настройки workflow в разных git-ветках.
  • Возможность переиспользовать приватные workflow в рамках организации в разных репозиториях.
  • Высокий uptime.

Минусы​

  • В качестве облачного CI комфортно использовать, только если кодовая база хостится на GitHub.
  • Нет возможности выбрать более мощные облачные машины.
  • Накладные расходы в случае, если необходимо обновить workflow во всех актуальных ветках.
  • UI для просмотра логов на больших объемах начинает сильно подтормаживать. Проще смотреть сырые логи.
  • Артефакты сборки прикрепляются как архив ко всему workflow и нет возможности просмотреть содержимое, не скачивая архив целиком.
GitHub Actions — еще один сервис для CI/CD на рынке. В случае, если GitHub уже заинтегрирован в ваши рабочие процессы, то GitHub Actions с большой вероятностью подойдут большинству проектов. Его легко запустить и настроить, простое и хорошо документированное API для создания ваших собственных actions и использование уже существующих actions, доступных на площадке GitHub.

 
Сверху