Гайди

Деплой проекта с помощью Gitlab Continuous Integration

Сервис GitLab, как основной конкурент GitHub-а, имеет свои плюсы и минусы (это помимо отечественных корней разработки). Однако с некоторых пор он получил карт-бланш для всех команд разработки, применяющих continuous integration (CI) – этот функционал стал быть встроенным прямо в движок. И – вуаля! – теперь GitLab не только популярное CVS-облако, но еще и полноценная платформа для тестинга и сборки проектов! Юнит-тесты, билды, публикация сборок (и кода) в сторонние хранилища – все это доступно прямо “из коробки”.
Рассмотрим все это богатство поближе.

Подключение CI в GitLab-е

Для начала, следует включить continuous integration для проекта в GitLab:

Основная “рабочая лошадь” для CI в GitLab-е – это runner. Схема работы всего процесса примерно такая:

1. push проекта в репозиторий
2. GitLab внимательно смотрит на файлы проекта и, если обнаруживает в корне файлик .gitlab-ci.yml – то задействует для проекта механизм continuous integration
3. GitLab выполняет поиск runner-а, который задействован для данного проекта. Runner – приложение для непосредственного выполнения continuous integration: тестирования, сборки и деплоя проекта.
   Потренироваться можно с gitlab public runner, однако этот сервис часто бывает загружен, ну и безопасность его, это вопрос.
4. yaml-файл автоматически передается runner-у, который выполняет сценарий из этого файла.
   Это могут быть как простые команды (например, деплой проекта в какое-то облако) либо сложный сценарий, с последовательным запуском докера, билдом проекта, тестированием и т.д.
5. Результаты работы runner-а отображаются в GitLab-е непосредственно рядом с соответствующим commit-ом.

Установка GitLab runner

Будем выполнять наш runner на девелоперской машине. После установки приложения под любую из распространенных ОС, получаем командный интерфейс к gitlab-ci-multi-runner.
Для того, чтобы runner получал задачи от GitLab-а, его нужно связать с соотв. аккаунтом и проектом. Для этого выполняем gitlab-ci-multi-runner с параметром register, после чего указываем url GitLab-а (а это может быть и локальный инстанс GitLab), и токен регистрации:

Теперь сервис раннера можно запустить через gitlab-ci-multi-runner run, переведя его в ожидание задачи от гитлаба.

Создаем YAML-скрипт для continuous integration

Еще раз напомним – операции для continuous integration описываются файлом .gitlab-ci.yml, находящимся в корне проекта GitLab. Синтаксис формата YAML требует некоторой подготовки для понимания, однако документация по нему есть.
Мы сделаем один вызов API нашей условной платформы через HTTP по примеру из документации.
В нашем примере, curl установлен на ПК, где запущен runner, а сам скрипт API имеет название s_script.js:

before_script:

- npm install

stages:

- deploy

deploy:

script:

- curl -X POST "https://api.some_portal.com/platform_api/SetS_scriptInfo/?account_id=1&api_key=2&required_s_script_name=foo" --data-urlencode s_script_script@s_script.js
Этот скрипт будет выполняться каждый раз при команде push в репозиторий GitLab.
Уверенно освоить GitLab на “боевых проектах” вы можете на нашем авторском курсе “L3-DevOps”.