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

Сервис GitLab, как основной конкурент GitHub-а, имеет свои плюсы и минусы (это помимо отечественных корней разработки). Однако с некоторых пор он получил карт-бланш для всех команд разработки, применяющих continuous integration (CI) – этот функционал стал быть встроенным прямо в движок. И – вуаля! – теперь GitLab не только популярное CVS-облако, но еще и полноценная платформа для тестинга и сборки проектов! Юнит-тесты, билды, публикация сборок (и кода) в сторонние хранилища – все это доступно прямо “из коробки”.
Рассмотрим все это богатство поближе.
Подключение CI в GitLab-е
Для начала, следует включить continuous integration для проекта в GitLab:
Основная “рабочая лошадь” для CI в GitLab-е – это runner. Схема работы всего процесса примерно такая:
- push проекта в репозиторий
- GitLab внимательно смотрит на файлы проекта и, если обнаруживает в корне файлик .gitlab-ci.yml – то задействует для проекта механизм continuous integration
- GitLab выполняет поиск runner-а, который задействован для данного проекта. Runner – приложение для непосредственного выполнения continuous integration: тестирования, сборки и деплоя проекта.
Потренироваться можно с gitlab public runner, однако этот сервис часто бывает загружен, ну и безопасность его, это вопрос. - yaml-файл автоматически передается runner-у, который выполняет сценарий из этого файла.
Это могут быть как простые команды (например, деплой проекта в какое-то облако) либо сложный сценарий, с последовательным запуском докера, билдом проекта, тестированием и т.д. - Результаты работы 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”.