GitLab CI/CD: пошаговое руководство по настройке. | Блог slurm.io
2026-02-19 17:08 Diff
https://slurm.io/blog/nastrojka-cicd-v-gitlab
  • /
  • /

Инженерам  •  ДевОпс  •  7 мая 2025 • 8 мин чтения

Введение

Автоматизация — базовая необходимость. Если каждый раз собирать проект вручную, тратить часы на деплой, при этом надеяться, что «ничего не отвалится», — это путь в никуда. Сегодня даже малые команды стремятся упростить процессы разработки. Именно здесь на сцену выходит GitLab CI/CD — мощный инструмент, позволяющий на лету внедрять изменения, тестировать и выкатывать продукт.

Представьте: вы отправляете коммит, далее без единого клика запускается сборка, проходят тесты, а новая версия автоматически оказывается на сервере. Без спешки. Без ошибок. Без ночных релизов.
Вот она — цель CI/CD в GitLab: автоматизировать рутину, минимизировать ошибки, ускорить релизы.

Собрали подробный туториал по GitLab CI/CD, чтобы настроить всё без типичных ошибок новичков — от установки Runner до первого успешного pipeline. Независимо от того, вы джун или уже уверенный мидл — материал будет полезен. С примерами, пояснениями, а также готовыми решениями.

Есть желание разобраться во всём на фундаментальном уровне — добро пожаловать на курс от Слерм! Узнайте, как автоматизировать интеграцию, доставку, ускорить разработку и снизить риски. Начните обучение сегодня и повысите свои профессиональные навыки!
👉 Курс от Slurm

Развертывание приложений с GitLab CI/CD

Развертывание — это финальный аккорд работы над приложением. Именно он определяет, насколько быстро и безошибочно пользователи получат ваши обновления. С помощью практик непрерывной интеграции/доставки можно сделать этот процесс не только быстрым, но и стабильным.

Что такое CI/CD

CI (Continuous Integration) — это практика, при которой каждое изменение кода автоматически проходит тесты и сборку.

CD (Continuous Delivery/Deployment) — это процесс автоматической доставки проверенного кода на сервер или в продакшн-среду.

Если команда не внедрила эти подходы, каждый релиз превращается в лотерею: ошибки всплывают в последний момент, баги копятся, а выкатывание новых фич откладывается.
После внедрения — релизы становятся быстрыми и безопасными.

С чего начать: подготовка проекта GitLab CI/CD

Чтобы настроить туториал, понадобится:

  • Репозиторий в GitLab.
  • Чёткое понимание этапов (build, test, deploy).
  • Установленный «бегун».
  • Конфигурационный файл .gitlab-ci.yml.

Именно .gitlab-ci.yml управляет всей автоматизацией.

Минимальный пример .gitlab-ci.yml

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Сборка проекта"

test_job:
  stage: test
  script:
    - echo "Запуск тестов"

deploy_job:
  stage: deploy
  script:
    - echo "Развертывание на сервере"

Этот файл определяет три этапа пайплайна: сборка, тестирование и развертывание. Каждый этап — это набор скриптов, которые выполняются автоматически.

Виды Runner'ов

  • Shared Runner — предоставляется всем пользователям платформы. Подходит для тестов, но часто перегружен.
  • Specific Runner — закрепляется за вашим проектом. Вариант для стабильной, быстрой работы.

Если хотите серьезно развивать автоматизацию, сразу планируйте настройку собственного «‎бегуна».

Ошибки при развертывании

  • Отсутствие тестов между сборкой и деплоем.
  • Перегруженные пайплайны, которые падают из-за мелочей.
  • Отсутствие механизма отката на случай неудачного релиза.

CI/CD не просто ускоряет работу. Он позволяет выстроить предсказуемый, надёжный процесс развертывания.

В гайде подробно разобрали этапы становления CI с использованием GitLab-CI.
Наглядно рассказываем и показываем, как написать правильный пайплайн: проверки, версионирование, реализация и другие этапы.

Заберите бесплатный гайд «Как организовать CI/CD с Gitlab»

Установка

Настроить пайплайн без «‎бегуна» невозможно: именно он выполняет все задачи в процессе CI/CD. Пора разобраться, как быстро, при этом правильно установить это ПО для своего проекта.

Что это такое?

«‎Бегун» — это отдельное приложение (высокомасштабируемый агент), которое подключается к вашему репозиторию, а затем исполняет команды, описанные в .gitlab-ci.yml. Оно может работать на любом сервере: локальной машине, VPS или в облаке.

Такие приложения бывают:

  • Shared — предоставляются платформой, общие для всех.
  • Specific — привязаны к вашему проекту.
  • Group — используются несколькими проектами в рамках одной группы.

Как установить?

Установка зависит от операционной системы. Пройдемся по самым популярным вариантам.

1. Ubuntu/Debian

sudo apt-get update
sudo apt-get install -y curl
curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
chmod +x /usr/local/bin/gitlab-runner
gitlab-runner --version

2.CentOS/RHEL

sudo yum install -y curl
curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
chmod +x /usr/local/bin/gitlab-runner
gitlab-runner --version

3.Windows

На Windows скачайте бинарник с официального сайта GitLab и добавьте путь к нему в переменные среды. Затем запустите:

gitlab-runner.exe install
gitlab-runner.exe start

4.Docker

Быстрое развертывание через контейнер:

docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

Docker — отличный вариант, если не хочется засорять основную систему.

Регистрация Runner'а

После установки необходимо привязать приложение к вашему проекту:

  1. Перейдите в настройки проекта: Settings → CI/CD → Runners → Expand.
  2. Найдите токен для регистрации.
  3. Выполните на сервере:

gitlab-runner register

Приложение попросит ввести:

  • URL вашего GitLab.
  • Токен регистрации.
  • Имя вашего агента.
  • Тип executor'а (например, shell, docker).

Важно: для начала выберите shell, это самый простой вариант. Позже можно перейти на docker для более продвинутой автоматизации.

Советы по настройке

  • Регулярно обновляйте «бегуна», чтобы исключить проблемы совместимости.
  • Следите за нагрузкой: если пайплайны начинают тормозить, стоит добавить ещё один Runner.
  • Настройте теги для агента, чтобы распределять задачи между разными исполнителями.

Овладейте эффективным CI/CD с помощью курса от Слёрм! Узнайте, как автоматизировать интеграцию и доставку, ускорить разработку и снизить риски. Начните обучение сегодня и повысите свои профессиональные навыки!
👉 Записаться на курс

Как настроить GitLab CI/CD

Теперь, когда «бегун» установлен и зарегистрирован, самое время настроить полноценный процесс CI/CD. Именно на этом этапе проект превращается из хаоса в управляемую систему с четкой логикой и автоматизацией.

Что делает .gitlab-ci.yml

Файл .gitlab-ci.yml — это сердце CI/CD в GitLab. Он определяет:

  • Этапы (stages): сборка, тестирование, деплой.
  • Задачи (jobs): конкретные действия на каждом этапе.
  • Условия запуска: когда и при каких событиях выполнять ту или иную задачу.
  • Переменные окружения: безопасная работа с ключами, логинами и паролями.

Все пайплайны начинают свою работу с анализа именно этого файла.

Структура базового .gitlab-ci.yml

stages:
  - build
  - test
  - deploy

variables:
  APP_ENV: production

build_job:
  stage: build
  script:
    - npm install
    - npm run build

test_job:
  stage: test
  script:
    - npm run test

deploy_job:
  stage: deploy
  script:
    - scp -r ./build user@server:/var/www/project
  only:
    - main

Этот пример демонстрирует процесс: установка зависимостей, сборка проекта, тестирование и загрузка собранной версии на сервер.

Практические советы по настройке

  • Декомпозируйте пайплайн: пусть каждый этап делает одну небольшую задачу.
  • Минимизируйте скрипты: переносите тяжелую логику в Makefile или bash-скрипты.
  • Используйте артефакты: сохраняйте результаты сборки между этапами.

Пример с артефактами:

build_job:
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - build/

Такой подход делает пайплайн надежным: если тесты или деплой отвалятся, результаты сборки не пропадут.

Оптимизация пайплайнов

При работе над крупными проектами, настройка требует продуманной оптимизации:

  • Используйте кэш для зависимостей:

cache:
  paths:
    - node_modules/

  • Параллельно запускайте независимые задачи через needs:

test_job:
  stage: test
  script: npm run test
  needs:
    - build_job

Это ускоряет весь процесс: пока одна задача работает, другая уже стартует.

Безопасность

Поскольку пайплайн часто взаимодействует с серверами и базами данных, нужно обезопасить секреты. Лучший способ — использовать переменные окружения в настройках проекта.

  • Settings → CI/CD → Variables — сюда добавляют логины, пароли, API-ключи.

Затем в .gitlab-ci.yml:

script:
  - curl -u "$USERNAME:$PASSWORD" https://example.com/deploy

Так никакие данные не попадут в лог пайплайна или исходный код.

Начните бесплатно изучать принципы работы CI/CD!
Дарим демодоступ к обучению на 3 дня, чтобы вы познакомились с материалами и спикерами курса.

Что делать, если пайплайн падает?

Ошибки — это часть работы над CI/CD. Чтобы быстрее их решать:

  • Включайте set -e в скриптах bash — он остановит выполнение при первой ошибке.
  • Используйте разметку логов (echo -e "\e[31mОшибка\e[0m") для удобной навигации.
  • Делите пайплайны на несколько коротких задач вместо одного длинного скрипта.

Подключение к внешним сервисам

Для продвинутой интеграции часто требуется работа с базами данных, кластерами Kubernetes, облачными платформами.

Подключение к Kubernetes через .gitlab-ci.yml:

deploy_job:
  stage: deploy
  image: bitnami/kubectl
  script:
    - kubectl apply -f k8s/deployment.yaml
  only:
    - main

Поддержка сторонних решений делает CI/CD мощным инструментом не только для сайтов, но и для микросервисов и больших распределенных систем.

Настройка пайплайна — это не разовая задача, а постоянное улучшение процессов. Начав с базового варианта, со временем вы сможете выстроить мощную, устойчивую систему доставки кода.

Проверка работы Pipeline

Создать .gitlab-ci.yml — это только половина дела. Теперь нужно убедиться, что пайплайн запускается корректно, задачи выполняются последовательно, а развертывание проходит без ошибок.

Как запустить пайплайн вручную

После коммита файла .gitlab-ci.yml платформа автоматически запустит конвейер. Но можно сделать это вручную:

  1. Перейдите в раздел CI/CD → Pipelines вашего проекта.
  2. Нажмите кнопку Run pipeline.
  3. Выберите ветку и нажмите Run.

Это полезно, если вы хотите протестировать изменения в пайплайне без лишних коммитов.

Как читать результаты

После запуска вы увидите список всех задач (jobs), разбитых по этапам (stages):

  • Зеленый значок ✅ — задача выполнена успешно.
  • Красный крест ❌ — ошибка.
  • Чёрные часики ⏳ — задача выполняется.

Кликнув на задачу, можно посмотреть логи её выполнения. Если пайплайн упал, платформа четко покажет, на каком шаге возникла проблема.

Распространённые ошибки

При первых попытках настроить gitlab ci cd часто возникают такие ошибки:

  • Неправильный синтаксис в файле.
  • Отсутствие прав у Runner'а на выполнение команд.
  • Проблемы с сетевыми подключениями при деплое.

Чтобы найти источник ошибки:

  • Проверьте логи задачи — ищите первую строку с ошибкой.
  • Внимательно перечитайте описание приложения, доступы в системе.
  • Убедитесь, что все переменные окружения заданы корректно.

Советы по улучшению пайплайна

  • Добавляйте before_script и after_script, чтобы избежать дублирования кода:

before_script:
  - npm install

after_script:
  - echo "Очистка завершена"

  • Разбивайте большие этапы на несколько мелких задач.
  • Настраивайте правила (rules) для разных веток:

deploy_job:
  stage: deploy
  script: ./deploy.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'

Таким образом деплой будет запускаться только для главной ветки.

Проверка деплоя

Если пайплайн дошёл до этапа deploy, стоит убедиться, что:

  • Код действительно оказался на сервере.
  • Приложение запускается без ошибок.
  • Старые версии файлов не мешают новой сборке.

Проверить можно через SSH-подключение или через интерфейс сервера.

Проверка пайплайна — важнейший этап внедрения рассматриваемых процессов. На этом этапе вы убедитесь, что автоматизация работает, а процесс доставки кода контролируем и прозрачен.

Заключение

Настройка процессов непрерывной интеграции/деплоя — это не просто модный этап в разработке. Это фундамент для стабильной, быстрой, а самое главное — безопасной работы команды. Даже базовая автоматизация сборки и деплоя способна сэкономить десятки часов времени и предотвратить критические ошибки на продакшене.

Документацию по использованию CI/CD для создания вашего приложения можно посмотреть на официальном источнике GitLab.

Давайте ещё раз кратко пройдем путь, который мы разобрали:

  • Подготовили проект, определили модель развертывания.
  • Установили и зарегистрировали «бегуна».
  • Создали первый .gitlab-ci.yml с этапами сборки, тестирования и деплоя.
  • Проверили конвейер в действии, наладили процесс автоматической доставки кода.

Каждый из этих шагов приближает проект к профессиональному уровню.
На этом этапе у вас уже есть основа, которую можно масштабировать, добавлять сложные проверки, интегрировать с Kubernetes или облачными платформами.

Конечно, на практике развивается вместе с проектом: по мере роста кода, команды и инфраструктуры вам придётся улучшать пайплайны, добавлять новые этапы и оптимизировать процессы.

Если вы хотите быстро поднять уровень своих знаний и научиться не просто настраивать пайплайны, а строить продвинутую инфраструктуру доставки — самое время двигаться дальше.

Освойте лучшие практики вместе с экспертами и начните автоматизировать свои процессы уже сегодня.

👉 Запишитесь на курс от Slurm — и сделайте первый шаг к новым вершинам в карьере!

Статью подготовили

Понравилась статья? Будем рады вашему лайку и репосту — вдруг кому-то тоже пригодится:)

Читайте также: