Pull to refresh
69.06
Voximplant
Облачная платформа голосовой и видеотелефонии

Использование gitlab continuous integration для деплоя

Reading time 4 min
Views 48K
Совсем недавно гитлаб героически выкатил версию 8.0 своего конкурента гитхабу. Из интересного — движок continuous integration теперь встроен в платформу, а значит доступен в качестве бесплатного сервиса для всех желающих на gitlab.com. Совместно с бесплатными приватными репозиториями это делает облачный сервис гитлаб не только удобным местом для хранения кода, но также тестирования и деплоя. О последнем я и расскажу под катом.


Continuous integration — это не только запуск юнит тестов при пуше нового кода в репозиторий. Это еще и возможность делать сборки продуктов, публиковать их в сторы, на сайты и в другие каналы распространения. Облачная телефония voximplant использует javascript сценарии, которые размещаются в нашем облаке и выполняются по команде “снаружи” или при поступлении входящего звонка. Многие клиенты для работы со сценариями используют встроенный в админку текстовый редактор, что вполне подходит для простых случаев. Но при разработке и поддержке сложных облачных систем, к примеру телефонии Bitrix24, нужно что-то более серьезное.


Создавая voximplant мы решили не делать push-to-deploy как у heroku. У многих наших клиентов основной бизнес не связан с разработкой софта, и оставлять их один на один с git’ом не очень хорошо. Зато есть HTTP API с функцией “задеплоить сценарий”, который намекает понимающим людям что сценарии можно хранить на gitlab и деплоить с помощью shell скрипта и curl. Большинство клиентов так и делает, но у подхода есть серьезный недостаток: скрипт нужно не забыть вызвать. Более того, вызывать его надо только если код был запушен в production ветку. И только после того, как прошли тесты. Вообще много способов ошибиться.


Настройка continuous integration в gitlab



По умолчанию continuous integration в гитлабе выключено и необходимо его включить в настройках:



После включения в левом меню настроек проекта появляется несколько новых пунктов, самый интересный для нас — это «runners». Continuous integration в гитлабе работает следующим образом:

  1. Вы делаете push в репозиторий
  2. Если в корне проекта есть файл .gitlab-ci.yml, то гитлаб понимает что для этого проекта будет использоваться continuous integration.
  3. Гитлаб ищет запущенный runner, подключенный для этого или для любого проекта. Runner — это приложение, которое обычно запускают на отдельном компьютере и которое будет собственно осуществлять continuous integration: прогонять тесты, собирать исполняемые файлы, осуществлять деплой. Можно запустить свой runner, к примеру на маке чтобы собрать приложение для iOS. Можно использовать “gitlab public runner”, но они не то чтобы очень безопасны и входящие очереди задач у них обычно многочасовые.
  4. Гитлаб передает yaml файл runner’у, который обновляет исходники в своем репозитории и выполняет команды, описанные в этом файле. Команды могут быть как простые, к примеру сделать деплой сценария в облако voximplant. Так и сложные: запуск docker контейнера, сборка в нем проекта, запуск тестов и так далее.
  5. После выполнения скриптов runner рапортует обратно гитлабу результаты, которые можно посмотреть рядом с соответствующим коммитом.


Установка gitlab ci runner


Для нашего примера мы запустим runner на машине разработчика. Инструкции по установки для windows/linux/osx доступна на официальном сайте, после установки мы получаем в свое распоряжение command line утилиту gitlab-ci-multi-runner. Запущенный runner подключается к гитлабу и ждет задачи на сборку. Но как гитлаб узнает, какие задачи какому runner’у давать? Чтобы “привязать” runner к своему аккаунту и проекту (или нескольким проектам) необходимо вызвать gitlab-ci-multi-runner с ключем register и ввести параметры подключение: url гитлаб (так как гитлаб может быть развернут локально в вашей сети) и токен регистрации, который, собственно, и определяет аккаунт/проекты:



Зарегистрированный runner запускается командой gitlab-ci-multi-runner run и ждет задачу от гитлаба. С помощью ключей командной строки install и start runner можно зарегистрировать в системе как сервис, чтобы он автоматически стартовал после перезагрузки операционной системы.

Конфигурация continuous integration для деплоя


Как я уже писал, задачи continuous integration описываются в файле .gitlab-ci.yml который необходимо разместить в корне проекта. Редкоземельный синтаксис YAML является как-бы-человекочитаемой альтернативой JSON’у, документация доступна на официальном сайте. Конфигурационный файл для деплоя проекта в voximplant будет максимально простым, все что нам нужно — это сделать один вызов HTTP API как описано в нашей документации. Если исходить из предположения, что runner выполняется на компьютере где установлен curl, а код сценария находится в файле scenario.js, то конфигурационный файл для деплоя будет выглядеть следующим образом (Упрощенный пример. Настоящий побольше будет, к примеру api_key имеет смысл вынести в переменную окружения, см. комментарий nmike):

before_script:
  - npm install
stages:
  - deploy
deploy:
  script:
  - curl -X POST "https://api.voximplant.com/platform_api/SetScenarioInfo/?account_id=1&api_key=2&required_scenario_name=foo" --data-urlencode scenario_script@scenario.js


В curl используется синтаксический сахар нашего API, которое может принимать аргументы как в компоненте query передаваемого url, так и в body http запроса.

Чтобы continuous integration заработал достаточно сделать push в репозиторий: гитлаб обнаружит файл .gitlab-ci.yml, найдет подключенный runner, передаст ему содержимое этого файла, runner обновит свою копию репозитория и запустит скрипт деплоя, который отгрузит исходный код в наше облако.

Вопросы, уточнения, комментарии? Gitlab vs Jenkins vs Bamboo vs Teamcity?
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+22
Comments 23
Comments Comments 23

Articles

Information

Website
www.voximplant.com
Registered
Founded
Employees
101–200 employees
Location
Россия