GitLab CI/CD (Непрерывная интеграция и доставка в GitLab)

GitLab CI/CD — это встроенный движок автоматизации внутри GitLab. То есть у вас в одном месте и репозиторий, и ревью, и пайплайны, и иногда даже мониторинг с безопасностью. Всё поведение пайплайна описывается в файле .gitlab-ci.yml, который лежит рядом с кодом и версионируется так же, как любые другие файлы.

Что обычно делает GitLab CI/CD #

• Запускает тесты и сборки при каждом пуше или создании merge request.
• Выкатывает приложение на staging или production автоматически либо после ручного триггера.
• Показывает состояние пайплайна: статусы, логи, граф зависимостей между job'ами и прочее.
• Интегрируется с Docker, Kubernetes, Helm, Terraform, Slack, Prometheus, Sentry и множеством других инструментов.
• Поддерживает DevSecOps: есть встроенные сканеры SAST, DAST, Dependency Scanning, Container Scanning, License Compliance.
• Умеет генерировать типовые пайплайны для распространённых стеков (Node.js, Python, Java и т.д.).

Ключевые элементы GitLab CI #

• Stages — последовательные этапы пайплайна: build, test, deploy, review, cleanup и любые свои.
• Jobs — конкретные задачи внутри этапов: например, «прогнать unit-тесты».
• Runners — агенты, которые физически выполняют job'ы (docker, shell, Kubernetes; shared или свои).
• Triggers — способы запуска пайплайнов: руками, по расписанию, через API.
• Artifacts — файлы, которые можно передавать между job'ами или скачивать после выполнения.
• Environments — описание окружений (staging, prod и т.д.), плюс управление rollout'ами и URL.

Пример простого .gitlab-ci.yml #

stages:
- test
- build
- deploy

test:
stage: test
image: node:20
script:
- npm ci
- npm run test

build:
stage: build
image: docker:latest
services:
- docker:dind
script:
- docker build -t registry.gitlab.com/mygroup/app:$CI_COMMIT_SHORT_SHA .
- docker push registry.gitlab.com/mygroup/app:$CI_COMMIT_SHORT_SHA

deploy:
stage: deploy
script:
- helm upgrade --install app ./helm 
--set image.tag=$CI_COMMIT_SHORT_SHA 
--namespace production
only:
- main

Такой пайплайн сначала гоняет тесты, потом собирает Docker-образ и отправляет его в registry, а затем деплоит в Kubernetes через Helm.

Чем GitLab CI/CD удобен #

• Всё в одной платформе: код, ревью, пайплайны, сканирование безопасности — не нужно склеивать несколько отдельных систем.
• Pipeline-as-Code: конфиг лежит в репозитории, можно ревьюить изменения пайплайна так же, как изменения кода.
• Гибкость: от одной-двух job до сложных многоконтурных пайплайнов со множеством окружений.
• Безопасность из коробки: DevSecOps-фичи не надо поднимать отдельно.
• Много настроек поведения: rules, only/except, переменные, матричные сборки, динамические child-пайплайны и так далее.

Поддержка DevOps и DevSecOps #

• SAST, DAST, Container Scanning, License Compliance включаются буквально одной-двумя строчками в .gitlab-ci.yml.
• Результаты сканов видны прямо в merge request — можно не лезть в отдельные отчёты.
• Security Dashboard показывает общую картину уязвимостей по проектам.
• Есть политики и approvals для продакшн-окружений и безопасности кода.

В итоге GitLab CI/CD — это не просто «запуск тестов на каждый push», а целая платформа, которая закрывает значимую часть DevOps-цепочки — от разработки и ревью до безопасности и деплоя.

Пример продвинутого .gitlab-ci.yml с несколькими стадиями, Docker, Helm и SAST #

stages:
- lint
- test
- build
- security
- deploy

variables:
IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA

lint:
stage: lint
image: node:20
script:
- npm ci
- npm run lint

test:
stage: test
image: node:20
script:
- npm run test:ci

build:
stage: build
image: docker:20
services:
- docker:dind
script:
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $IMAGE_TAG .
- docker push $IMAGE_TAG

security-sast:
stage: security
image: docker:20
allow_failure: true
script:
- docker run --rm -v $(pwd):/src returntocorp/semgrep --config=auto
rules:
- if: '$CI_COMMIT_BRANCH == "main"'

deploy-prod:
stage: deploy
image: alpine/k8s:1.27.4
script:
- helm upgrade --install app ./helm 
--namespace production 
--set image.repository=$CI_REGISTRY_IMAGE 
--set image.tag=$CI_COMMIT_SHORT_SHA
only:
- main

Пример job для динамических review apps (на каждый merge request) #

review:
stage: deploy
environment:
name: review/$CI_COMMIT_REF_NAME
url: https://$CI_COMMIT_REF_SLUG.example.com
script:
- helm upgrade --install app-$CI_COMMIT_REF_SLUG ./helm 
--namespace review 
--set image.tag=$CI_COMMIT_SHORT_SHA 
--set ingress.host=$CI_COMMIT_REF_SLUG.example.com
only:
- merge_requests

Такой job поднимает временное окружение под каждую ветку в merge request, чтобы можно было покликать новую версию до слияния.

GitLab Runner в Docker (standalone-вариант) #

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

После запуска runner нужно зарегистрировать:

docker exec -it gitlab-runner gitlab-runner register

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

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

Арендовать VPS