GitLab CI

GitLab CI/CD — встроенный инструмент автоматизации в GitLab Platform. Пайплайны описываются в YAML-файле .gitlab-ci.yml в корне репозитория. При каждом push GitLab запускает пайплайн на GitLab Runner — агенте, работающем на собственном сервере, в Docker или Kubernetes. Занимает около 30% рынка DevOps-платформ среди on-premise решений.

Структура .gitlab-ci.yml

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: node:20
  script:
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/

deploy_production:
  stage: deploy
  script:
    - ssh deploy@server "cd /app && git pull && pm2 restart app"
  environment:
    name: production
  only:
    - main

GitLab Runner

GitLab Runner — агент, выполняющий задачи пайплайна. Типы исполнителей (executor):

• Docker — каждый job в изолированном контейнере; рекомендован для большинства задач
• Shell — выполнение напрямую в shell сервера; проще, но без изоляции
• Kubernetes — запуск в Kubernetes pod для масштабируемых сборок
• SSH — выполнение на удалённом сервере по SSH

Shared Runners от GitLab.com — бесплатно 400 минут CI/мес для Free плана. Для больших объёмов или приватной инфраструктуры устанавливается собственный Runner на VPS или выделенном сервере.

История

GitLab CI появился как отдельный продукт в 2012 году, созданный Дмитрием Запорожцем. В 2015 году интегрирован в GitLab 8.0 как встроенный компонент. В 2017 году добавлен Auto DevOps — автоматическое создание пайплайнов без написания .gitlab-ci.yml. В 2021 году GitLab провёл IPO на NASDAQ при оценке $18 млрд. GitLab занимает около 30% рынка DevOps-платформ среди on-premise решений по данным 2022 года.

Применение в хостинге

Типичный сценарий деплоя на VPS через GitLab CI:

1. Добавить SSH-ключ деплоя в GitLab CI/CD Variables как SSH_PRIVATE_KEY
2. В deploy-job настроить SSH-соединение и выполнить деплой-команды
3. Настроить environment protection rules для production (require approval)

Для отката к предыдущей версии используется GitLab Environments: каждый деплой фиксируется в истории, откат — одна кнопка в интерфейсе. Конвейеры GitLab CI полностью интегрированы с Docker Container Registry, что упрощает Docker-based деплой: образ собирается, пушится в реестр и затем деплоится на сервер командой docker pull. Staging-среда настраивается через отдельный environment с автодеплоем при merge в develop-ветку.

Кэширование в GitLab CI

Кэш зависимостей ускоряет пайплайны. Node.js-проект без кэша: npm install за 2-3 минуты каждый раз. С кэшем директории node_modules:

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - node_modules/

Первый раз кэш создаётся, последующие запуски используют кэшированные модули — время установки сокращается до 10-20 секунд. Артефакты (artifacts) — файлы, сохраняемые между стадиями одного пайплайна: собранный бинарник, отчёты тестов. Артефакты хранятся 30 дней по умолчанию и доступны для скачивания из интерфейса.

Security в GitLab CI

GitLab Ultimate включает SAST (Static Application Security Testing), DAST (Dynamic), Secret Detection (поиск паролей в коде) и Container Scanning прямо в пайплайне. Бесплатные аналоги: trivy для сканирования образов, gitleaks для поиска секретов, semgrep для SAST.

GitLab CI vs GitHub Actions

GitLab CI предпочтительнее для команд, требующих полного on-premise контроля: GitLab Community Edition бесплатен для self-hosted установки и включает все базовые CI/CD-возможности. Bitbucket Pipelines удобнее при работе в экосистеме Atlassian.