...

пятница, 20 апреля 2018 г.

Как переехать с BuddyBuild на GitLab CI за 4 часа


Предыстория


Полтора года назад команда iOS FunCorp переехала на новый сервис для простой организации CI в iOS и Android-проектах.
До этого мы использовали CI на Bamboo, но с ним было много проблем, поэтому мы совсем отказались от него и перешли на BuddyBuild.
Он работал настолько просто, что можно было даже не знать, что такое CI и как заливать приложение в AppStore, а спокойно заниматься кодом, тестами и продуктовой разработкой.
Но времена поменялись, и BuddуBuild уже не тот, поэтому мы начали поиск альтернативы.
В этой статье мы расскажем о новом решении, которое выбрала наша команда, и дадим несколько скриптов для организации CI собственными силами.

Просто — значит хорошо


В BuddyBuild нас привлекла простота. Для начала нужно сделать всего несколько шагов:
  1. Авторизоваться через GitHub/GitLab/BitBucket.
  2. Указать репозиторий с проектом.
  3. Отдать сервису аккаунт и distribution-сертификат.
  4. Подождать, пока «случится магия» на стороне сервиса.

И сразу после этого можно получать тесты и артефакты по всем веткам, настраивать правила сборки с помощью понятного UI, быстро переключаться между версиями XCode и релизить в AppStore/TestFlight прямо из сервиса.
Когда мы начинали работать с BuddyBuild, его можно было использовать бесплатно, но через несколько месяцев это закончилось. Сейчас стартовый пакет стоит $79 в месяц. Для себя мы выбрали план с тремя конкурентными сборками за $279.
BuddyBuild работал хорошо, но это длилось недолго.
С ростом популярности сервиса, а также с увеличением количества кода в iFunny время сборки увеличилось со стабильных 20 минут на тесты и сборку артефакта до 70 минут.
Мы пробовали найти решение для кеширования средствами сервиса, но ничего достойного в простых настройках не нашлось.
Тем временем сервис выкупила Apple, и мы приняли окончательное решение от него отказаться.

Требования к CI/CD


Исходя из предыдущего опыта работы с CI, у нас было несколько требований к новой системе.
  1. Она должна быстро разворачивать агентов и среду для сборки с минимальным количеством заходов в UI агентов.
  2. Обновлять Xcode без захода в UI агента и иметь возможность переключения между несколькими версиями.
  3. Интегрироваться с системой pull requests.
  4. Использовать минимум сторонних зависимостей для сборки и выгрузки в AppStore.
  5. Иметь возможность настраивать и кастомизировать шаги сборки для разных веток.
  6. Запускать сборку артефакта только по кнопке из UI.

GitLab CI


Вместе с решением отказаться от BuddyBuild появилась идея мигрировать c GitHub на GitLab, а в нём уже есть встроенная CI/CD система, то есть присутствует необходимая нам интеграция с merge requests.

Установка рабочего окружения на агента


Первым делом нужно включить возможность доступа к агенту по SSH с помощью Screen Sharing. Это делается в настройках Sharing:

Теперь, чтобы подключаться к CI-агенту, мы можем использовать терминал и SSH-клиент: 
ssh user@local.ip

После успешного подключения по SSH нужно отключить использование пароля для команды sudo. Может показаться, что это небезопасно, но с учётом, что все агенты у нас доступны только внутри локальной сети, для лучшей автоматизации мы отключаем пароль для sudo. Для этого: 
sudo visudo

Откроется стандартный редактор Vim, в котором нужно поменять строку: 
%admin            ALL = (ALL) ALL

на строку 
%admin          ALL = (ALL) NOPASSWD: ALL

Многие iOS-разработчики не любят копаться в консоли и редко используют Vim, поэтому держите пошаговую инструкцию, как поменять эти строки:
  1. Нажимаем i, входим в режим insert.
  2. Стрелками находим нужную строку и меняем её.
  3. Далее esc.
  4. Вводим :w для сохранения.
  5. Вводим :q для выхода из visudo.

Первым делом на каждом агенте нам понадобится менеджер пакетов Homebrew, который можно установить следующей командой: 
sudo echo | ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Здесь используется команда echo, чтобы не появлялся запрос на подтверждение установки.
После этого можно установить необходимый минимум зависимостей из Homebrew. Вот что мы выбрали:
  • XCPretty. Он позволяет красиво форматировать вывод стандартной команды для билда iOS-проектов xcodebuild; 
    sudo gem install xcpretty
  • fastlane. Его возможности мы используем по минимуму, так как не хотим, чтобы билд проекта сильно зависел от чего-то стороннего; 
    sudo gem install fastlane
  • xcode-install. Этот инструмент позволит устанавливать Xcode без захода в AppStore и переключаться между несколькими версиями; 
    sudo gem install xcode-install
  • CocoaPods. Этот менеджер зависимостей знаком каждому iOS-разработчику. 
    sudo gem install cocoapods


Теперь можно установить Xcode, запустив последовательно команды: 
export FASTLANE_USER="your@account.todevapple"
export FASTLANE_PASSWORD="yourpasswordtoaccont"
xcversion install 9.2

Можно не выполнять export, но тогда e-mail и пароль от Apple ID будут запрошены в процессе установки.
После этих несложных действий агент готов к тому, чтобы собирать большинство iOS-проектов.

Регистрация агента


Для того чтобы проект на Gitlab CI увидел ваш агент, необходимо установить его и зарегистрировать.
Это также можно выполнить с помощью SSH и командной строки на агенте:
Сначала скачиваем и устанавливаем агента: 
curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64

Даём права на выполнение: 
chmod +x /usr/local/bin/gitlab-runner

Устанавливаем gitlab-runner как сервис и запускаем его: 
gitlab-runner install
gitlab-runner start

Теперь нужно зарегистрировать runner на CI, это выполняется командой: 
gitlab-runner register -n --url CI_URL --registration-token TOKEN --tag-list fastlane,cocoapods,osx_10-13,xcode_9-2 --executor shell

Это команда, которую стоит пояснить подробно.
CI_URL и TOKEN можно взять в настройках проекта на GitLab:
Settings -> CI/CD -> Runners ->блок Setup a specific Runner manually
--tag-list: указываются теги, которые потребуются нам далее при настройке самого проекта.
Их также можно будет менять, например, в зависимости от того, какие версии Xcode установлены на агенте или какой тип задач мы планируем выполнять на нём.
--executor shell: указываем, что на агенте необходимо выполнять действия в командной строке.
Чтобы не возникло проблем с CocoaPods, также нужно выполнить команды: 
echo 'export LC_ALL="en_US.UTF-8"' >> ~/.bash_profile
echo 'export LANG=en_US.UTF-8' >> ~/.bash_profile

Это необходимо, чтобы при установке подов не было ошибок с кодировкой.
После успешной регистрации агента его можно будет увидеть в настройках.
Settings -> CI/CD -> Runners

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


Осталось настроить Xcode-проект для работы с GitLab CI.
Сделать это достаточно просто: нужно положить файл .gitlab-ci.yml с описанием в корень проекта.
После того как данный файл будет добавлен в репозиторий, CI система начнёт выполнять команды, указанные в нём.
Пример нашего yml-файла: 
stages:
  - test
  - archive

before_script:
    - git submodule init
    - git submodule update --recursive
    - pod install --repo-update

archive_project:
  stage: archive
  script:
    - fastlane match appstore
    - xcodebuild -workspace iFunny.xcworkspace -scheme iFunny archive -archivePath build/iFunny.xcarchive | xcpretty
  only:
    - master
    - triggers
    - web
  artifacts:
    paths:
    - build/iFunny.xcarchive
  tags:
    - xcode_9-2
    - osx_10-13
    - cocoapods
    - fastlane

test_project:
  stage: test
  script:
    - xcodebuild test  -workspace iFunny.xcworkspace -scheme iFunny -destination 'platform=iOS Simulator,name=iPhone 7,OS=11.2' | xcpretty
  tags:
    - xcode_9-2
    - osx_10-13
    - cocoapods
    - fastlane

yml-формат для GitLab CI достаточно хорошо описан здесь:
docs.gitlab.com/ee/ci/yaml
Чтобы можно было легко использовать пример файла, опишу основные моменты, которые используем мы:

  • before_script — описываем набор инструкций, которые необходимо выполнять перед каждой работой на CI. Для нас это стандартный набор из обновления сабмодулей и установки подов;
  • archive_project — название, которое используется, для получения артефакта с xcarchive.

В script указываем все инструкции, которые необходимо выполнить: 
fastlane match appstore

Для синхронизации сертификатов у fastlane есть хорошая команда match (подробнее про использование match можно прочитать на сайте fastlane:
docs.fastlane.tools/actions/match).

Основная команда на запуск сборки архива:

xcodebuild -workspace Project.xcworkspace -scheme ProjectScheme archive -archivePath build/Project.xcarchive | xcpretty

Project.xcworkspace — файл с workspace.
ProjectScheme — схема с основным таргетом.
build/Project.xcarchive — путь, по которому соберётся рабочий артефакт. Далее этот путь используем в artifacts: он указывает CI, откуда нужно забрать архив.
В блоке only указываем, что данную работу нужно выполнять только на ветке мастер или при запуске из веба, то есть при запуске по кнопке Run Pipeline в CI/CD.
tags — это те теги, которые должны быть прописаны на агенте, чтобы он мог запускать эту работу. Сейчас они полностью повторяют то, что мы указывали при регистрации агента.
Далее в файле идёт описание работы test_project.
Из интересного здесь — строка запуска тестов: 
xcodebuild test  -workspace Project.xcworkspace -scheme ProjectScheme -destination 'platform=iOS Simulator,name=iPhone 7,OS=11.2' | xcpretty

В настройке -destination указываем тот симулятор, который точно доступен на агентах.
Посмотреть список доступных устройств на агенте можно через SSH командой: 
instruments -s list

После того как будет сконфигурирован файл .gitlab-ci.yml, можно добавлять его в репозиторий и автоматически будет произведён запуск тестов в ветке, содержащей файл.

Заключение


Чтобы настроить всю связку GitLab и встроенной CI/CD-системы, мы потратили примерно половину рабочего дня, что несколько больше 20 минут, потраченных на настройку BuddyBuild.
Но что мы получили от переезда:
  • собственных агентов для сборки проектов и систему работы с ними;
  • удалось сократить с 70 до 6 минут время на сборку с тестами или до 30 минут на полную сборку с тестами и архивами;
  • возможности для оптимизации времени сборок;
  • нам доступна любая кастомизация и интеграция с любым сервисом.

Для нашей команды GitLab CI — это временное решение, сейчас мы готовимся к переезду на Jenkins, в котором добавим ещё больше автоматизации в проект.
Возможно, описанный в статье опыт позволит читателям переехать на GitLab CI менее чем за 4 часа.
А чтобы это легче было сделать, вот пара скриптов с командами, описанными в статье:

Let's block ads! (Why?)

на
Ярлыки: ,

Комментариев нет:

Отправить комментарий

Подписаться на: Комментарии к сообщению (Atom)