Меня зовут Валерий Кузнецов и я работаю Senior Android Engineerом в ThredUP. Хочу рассказать почему и как мы переезжали с Jenkins на GitHub Actions в качестве CI/CD системы для Android-приложения и как мы сделали автоматизацию, которая экономит нам время и силы на проверку и релиз наших приложений.
Статья будет полезна тем, кто хостит исходный код проектов на GitHub и хотел бы попробовать или перейти на новый инструмент для сборки и релиза своих приложений.
Наше приложение развивалось, команда расширялась, и мы стали планировать большое количество улучшений и автоматизации наших рабочих процессов: от проверки кода до релиза в продакшен. Исторически сложилось, что сборка нашего Android-приложения была настроена на Jenkins и работала на self-hosted машинах, но из-за ограничений внешних ресурсов для обновления машин, Jenkins-версий, билд-скриптов, мы решили посмотреть на облачные альтернативы. Как раз в тот момент GitHub выпустил продукт под названием GitHub Actions в Beta-доступ.
Иерархия компонентов
Все workflow хранятся .github/workflows-папке в репозитории проекта, что удобно с точки зрения контроля-версий, но и создает некоторые трудности, когда надо обновить файл workflow во всех актуальных ветках.
Гиф редактора с примером автозаполнения
Также есть неофициальный VS-плагин для работы с GitHub Actions.
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 состоит из следующих частей:
- 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
run: fastlane dev
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
GitHub Actions использует Standard_DS2_v2 машины с 2 vCPU и 7 Гб оперативной памяти в рамках Microsoft Azure. Также есть возможность собрать свое окружение и запускать workflow в рамках собственных локальных машин, подключаемых к GitHub Actions с целью кастомизации программного обеспечения и оборудования.
Источник: github.com/features/actions
Нам вполне хватает 50 000 минут работы на Linux-машинах, но в случае, если захотим подключить Windows или macOS-машины, то минуты начнут потребляться с повышенным коэффициентом — x2 за Windows, x10 за macOS.
Мы проводили базовое сравнение с альтернативой, которую рассматривали, — Bitrise, и аналогичное количество минут (50 000) на Linux-билд машинах стоило бы нам порядка $1755 в месяц со всеми скидками.
Статья будет полезна тем, кто хостит исходный код проектов на GitHub и хотел бы попробовать или перейти на новый инструмент для сборки и релиза своих приложений.
Наше приложение развивалось, команда расширялась, и мы стали планировать большое количество улучшений и автоматизации наших рабочих процессов: от проверки кода до релиза в продакшен. Исторически сложилось, что сборка нашего Android-приложения была настроена на Jenkins и работала на self-hosted машинах, но из-за ограничений внешних ресурсов для обновления машин, Jenkins-версий, билд-скриптов, мы решили посмотреть на облачные альтернативы. Как раз в тот момент GitHub выпустил продукт под названием GitHub Actions в Beta-доступ.
Почему GitHub Actions?
На тот момент уже было довольно много других облачных альтернатив CI/CD ч (Bitrise, CircleCI, Travis), даже с фокусом на мобильную разработку, но GitHub Actions показался нам привлекательным по двум простым причинам:- В Enterprise-план GitHub уже включено 50,000 минут. Никаких дополнительных оплат или согласований не надо.
- Actions являются частью большой GitHub-экосистемы, что несет за собой дополнительные преимущества в виде защищенности, поддержки, открытости исходного кода для некоторых частей системы.
Компоненты
Github Actions работает, используя следующие основные компоненты:- Workflows — самый высокоуровневый компонент, содержащий всю необходимую информацию о работе, которую нужны выполнить (и после каких событий).
- Events — это конкретное событие, запускающее workflow. Например, создание pull request, issue в репозитории, git push в конкретную ветку репозитория или же веб-хук, вызванный сторонним сервисом.
- Jobs — это набор шагов, которые выполняться на одной билд-машине.
- Steps — исполняемая часть в рамках Job. В качестве исполняемого шага может быть actions или простой сценарий командной строки. Все шаги внутри одной Job выполняются в рамках одной билд-машины, и это позволяет им обмениваться данными друг с другом.
- Actions — это самый маленький исполнимый и переиспользуемый блок workflow.
WorkFlows
Для того, чтобы начать работу GitHub Actions, требуется создать файл workflow в формате .yml или .yaml в папке проекта .github/workflows/. В этих файлах содержаться все настройки и шаги, необходимые для выполнения автоматизации. Workflow можно использовать для сборки, тестирования, релиза ваших проектов, а также любых других автоматизаций работы, связанных проектом на GitHub (например, при создании issue автоматически ответить каким-то шаблоном). Вот простой пример того, как может выглядеть workflow для сборки Android-приложения:Actions
Actions — это особый тип шагов, которые помогают нам автоматизировать CI/CD. Кто угодно может опубликовать свои Actions с открытым исходным кодом, и их можно просматривать через GitHub или же создать приватные и использовать их в рамках одной организации.Редактор
WorkFlow в GitHub Actions используют YAML в качества основного языка для конфигураций. Есть веб-редактор с поддержкой подсказок для автозаполнения.Все workflow хранятся .github/workflows-папке в репозитории проекта, что удобно с точки зрения контроля-версий, но и создает некоторые трудности, когда надо обновить файл workflow во всех актуальных ветках.
Также есть неофициальный 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
- Настройки окружения для сборки проекта:
- 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.
run: fastlane dev
- В случае ошибки сборки проекта запускаем ReviewDog для того, чтобы отправить ошибки, связанные со стилем кода в качестве комментариев на Pull Request.
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 работает на базе вирутальных окружений и предоставляет следующие готовые окружения:GitHub Actions использует Standard_DS2_v2 машины с 2 vCPU и 7 Гб оперативной памяти в рамках Microsoft Azure. Также есть возможность собрать свое окружение и запускать workflow в рамках собственных локальных машин, подключаемых к GitHub Actions с целью кастомизации программного обеспечения и оборудования.
Стоимость
Нам вполне хватает 50 000 минут работы на Linux-машинах, но в случае, если захотим подключить Windows или macOS-машины, то минуты начнут потребляться с повышенным коэффициентом — x2 за Windows, x10 за macOS.
Мы проводили базовое сравнение с альтернативой, которую рассматривали, — Bitrise, и аналогичное количество минут (50 000) на Linux-билд машинах стоило бы нам порядка $1755 в месяц со всеми скидками.
Значок статуса
Также можно добавить значок статуса выполнения автоматизации, если открыть детали workflow -> настройки -> создать значок статуса.Заключение
Подведем итоги плюсов и минусов, с которыми мы столкнулись во время интеграции и которые всплыли спустя 10000 запусков наших автоматизаций:Плюсы
- Довольно простая первичная настройка за счет интеграции с GitHub-экосистемой, хорошей документацией и возможности просмотреть workflow проектов с открытым исходным кодом.
- Большое и постоянно растущее количество actions с открытым кодом, покрывающее совершенно различные сценарии использования. На момент написания статьи их 10334.
- Версионирование workflow, так как они являются частью git-репозитория и помогают с откатом настроек. Есть возможность иметь разные настройки workflow в разных git-ветках.
- Возможность переиспользовать приватные workflow в рамках организации в разных репозиториях.
- Высокий uptime.
Минусы
- В качестве облачного CI комфортно использовать, только если кодовая база хостится на GitHub.
- Нет возможности выбрать более мощные облачные машины.
- Накладные расходы в случае, если необходимо обновить workflow во всех актуальных ветках.
- UI для просмотра логов на больших объемах начинает сильно подтормаживать. Проще смотреть сырые логи.
- Артефакты сборки прикрепляются как архив ко всему workflow и нет возможности просмотреть содержимое, не скачивая архив целиком.
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua