GitLab CI/CD - это встроенная система непрерывной интеграции и доставки (Continuous Integration / Continuous Delivery), которая является частью GitLab и не требует установки сторонних инструментов. Она позволяет автоматизировать сборку, тестирование, проверку безопасности и деплой приложений.

Что такое CI/CD простыми словами

CI (Continuous Integration) - практика, при которой разработчики часто сливают код в общий репозиторий, а система автоматически:

  • собирает проект;
  • запускает тесты;
  • проверяет качество кода.

CD (Continuous Delivery / Deployment) - автоматизация доставки приложения:

  • выкладка на staging;
  • деплой в production;
  • управление версиями и окружениями.

GitLab CI/CD объединяет всё это в одном месте - прямо рядом с репозиторием.

Как работает GitLab CI/CD в целом

  1. Разработчик делает git push
  2. GitLab находит файл .gitlab-ci.yml
  3. Создаётся pipeline
  4. Pipeline состоит из stages
  5. В каждом stage выполняются jobs
  6. Jobs выполняются runners
  7. Результаты сохраняются как artifacts
  8. Код деплоится в environments

Stages - этапы пайплайна

Stages - это логические этапы, которые выполняются последовательно.

Пример типичного пайплайна:

build - test - deploy - cleanup
  • следующий stage начнётся только если предыдущий прошёл успешно;
  • внутри одного stage jobs выполняются параллельно.

Пример описания stages:

stages:
  - build
  - test
  - deploy

Jobs - конкретные задачи

Job - это конкретное действие внутри stage:

  • установка зависимостей;
  • запуск тестов;
  • сборка Docker‑образа;
  • деплой.

Job:

  • всегда относится к одному stage;
  • описывает script - набор команд;
  • выполняется в изолированном окружении.

Пример job:

unit_tests:
  stage: test
  script:
    - php vendor/bin/phpunit

Runners - кто выполняет job'ы

GitLab Runner - это агент, который физически выполняет job.

Типы executors:

  • shell - выполнение прямо на сервере;
  • docker - запуск в контейнере;
  • kubernetes - job как pod;
  • docker+machine - динамические VM.

Типы runners:

  • Shared runners - предоставлены GitLab;
  • Specific runners - ваши собственные.

Runner:

  • забирает job;
  • поднимает окружение;
  • выполняет script;
  • отправляет результат в GitLab.

Triggers - как запускаются пайплайны

Pipeline может запускаться:

  • автоматически при push / merge request;
  • вручную (manual job);
  • по расписанию (cron);
  • через API;
  • из другого pipeline.

Пример ручного запуска:

deploy_prod:
  stage: deploy
  script: ./deploy.sh
  when: manual

Artifacts - файлы между job'ами

Artifacts - это файлы, которые:

  • сохраняются после job;
  • могут быть переданы в следующий stage;
  • доступны для скачивания.

Примеры:

  • собранный frontend;
  • coverage‑отчёты;
  • .env файлы;
  • бинарники.

Пример:

artifacts:
  paths:
    - vendor/
  expire_in: 1 hour

Environments - окружения и деплой

Environment описывает целевое окружение:

  • staging
  • production
  • review/*

GitLab умеет:

  • показывать активные окружения;
  • хранить URL;
  • делать rollback;
  • управлять rollout.

Пример:

environment:
  name: staging
  url: https://staging.example.com

Полный пример .gitlab-ci.yml для PHP приложения

image: php:8.2

stages:
  - build
  - test
  - deploy

variables:
  APP_ENV: test

cache:
  paths:
    - vendor/

build:
  stage: build
  script:
    - apt-get update && apt-get install -y unzip git
    - curl -sS https://getcomposer.org/installer | php
    - php composer.phar install
  artifacts:
    paths:
      - vendor/

phpunit:
  stage: test
  script:
    - php vendor/bin/phpunit

lint:
  stage: test
  script:
    - php -l src/

deploy_staging:
  stage: deploy
  script:
    - echo "Deploy to staging"
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - main

- Подробное объяснение конфигурации

image: php:8.2

Docker‑образ, в котором будут выполняться все job'ы.

variables:
  APP_ENV: test

Переменные окружения, доступные во всех job'ах.

cache:
  paths:
    - vendor/

Позволяет переиспользовать зависимости между пайплайнами.

- build stage

  • устанавливает зависимости;
  • сохраняет vendor/ как artifact;
  • ускоряет последующие job'ы.

- test stage

  • phpunit - юнит‑тесты;
  • lint - проверка синтаксиса;
  • jobs выполняются параллельно.

- deploy stage

  • запускается только из main;
  • привязан к environment staging;
  • отображается в UI GitLab.

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

GitLab CI/CD поддерживает:

- DevOps

  • Infrastructure as Code
  • автоматический деплой
  • monitoring

- DevSecOps

  • SAST
  • DAST
  • Dependency Scanning
  • Secret Detection

Всё это можно включить без внешних инструментов.

Source: Orkhan Alishov's notes