GitLab — репозитории, CI/CD и агентные функции в одной платформе

Практический справочник по GitLab: как устроена платформа, чем различаются тарифы, как собрать первый пайплайн и в каких случаях GitLab заменяет связку из отдельных сервисов.

Что такое GitLab

GitLab закрывает весь путь кода в одном веб-приложении: хранение репозиториев, code review через merge request, автоматические сборки и деплой, реестры пакетов и контейнеров, сканирование уязвимостей, задачи и планирование. Одна учётная запись, один интерфейс, одна система прав доступа.

Платформа работает в трёх вариантах поставки: облако GitLab.com, установка на своих серверах (Self-Managed) и изолированное облако под одного клиента (GitLab Dedicated). Функциональность различается тарифом, а не вариантом поставки.

Основные возможности

Тарифы и лимиты

Цифры относятся к GitLab.com и проверены 30 июля 2026 года.

Полезные детали, которые влияют на расчёт бюджета:

• Дополнительные compute-минуты стоят 10 $ за 1 000 минут разовым платежом, действуют 12 месяцев с даты покупки и переходят на следующий месяц, если остались неизрасходованными. Дополнительное хранилище — 5 $ в месяц за 10 GiB при годовой оплате, при этом потолок 500 GiB на отдельный проект покупка не поднимает.
• Аккаунты, созданные на Free после 27 января 2026 года, ограничены тремя верхними группами; личное пространство в этот лимит не входит. Тот же лимит действует в триале Ultimate.
• Кредиты Duo на тарифах Premium и Ultimate выданы как промо после выхода Agent Platform, и GitLab может изменить их состав.
• Открытые проекты, образовательные учреждения и стартапы могут получить бесплатный Ultimate с квотой 50 000 минут через программы GitLab for Open Source, Education и Startups.

С чего начать: первый проект

1. Зарегистрируйтесь на gitlab.com и создайте группу. Группа, а не личное пространство, нужна для подписки, покупки минут и хранилища.
2. Создайте проект внутри группы: New project → Create blank project.
3. Подключите локальный репозиторий и отправьте первый коммит.

   # инициализация локального репозитория
   git init
   git remote add origin https://gitlab.com/<группа>/<проект>.git
   git add .
   git commit -m "Первый коммит"
   git push -u origin main

4. Выдайте права участникам: Manage → Members. Роль Maintainer или Owner нужна, чтобы запускать и настраивать пайплайны.
5. Секреты передавайте только через переменные CI/CD: Settings → CI/CD → Variables, флаги Masked и Protected. В репозитории токенов быть не должно.

Первый пайплайн в .gitlab-ci.yml

Пайплайн описывается файлом .gitlab-ci.yml в корне репозитория. Как только файл появляется в ветке, GitLab запускает пайплайн на каждый пуш.

stages:
  - build
  - test

build-job:
  stage: build
  image: node:22-alpine   # окружение задания
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/            # передаём результат следующим стадиям
    expire_in: 1 week

test-job:
  stage: test
  image: node:22-alpine
  script:
    - npm ci
    - npm test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"  # проверяем каждый MR
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Задания одной стадии выполняются параллельно, стадии идут последовательно. Проверить синтаксис до пуша можно во встроенном редакторе: Build → Pipeline editor, вкладка Validate.

Раннеры: общие и свои

Задания выполняет раннер — процесс, который забирает задание и запускает его в контейнере или на машине.

• Общие раннеры облака работают сразу, но расходуют compute-минуты по квоте тарифа. Квота считается только для раннеров самого облака.
• Собственные раннеры устанавливаются на вашем сервере через GitLab Runner. Время их работы не расходует квоту и не ограничено, а стоимость сводится к стоимости железа.

Свой раннер имеет смысл, когда пайплайны длинные, нужны специфичное окружение, GPU или доступ к внутренней сети. Для проверки достаточно одного раннера с executor docker и тега, который вы указываете в задании через ключ tags.

GitLab Duo и Agent Platform

GitLab Duo — набор AI-функций внутри платформы: чат по коду и объектам проекта, подсказки при написании кода, объяснение ошибок пайплайна, помощь в ревью.

GitLab Duo Agent Platform стала общедоступной в релизе 18.8 (15 января 2026 года). Это слой оркестрации агентов, которые превращают issue в merge request, исправляют уязвимые зависимости и проводят ревью по правилам, заданным командой. Требуется тариф Premium или Ultimate, расход считается кредитами GitLab. Для собственной установки минимальная версия — 18.8, а для триала Ultimate с кредитами нужна 18.9.

GitLab.com, Self-Managed или Dedicated

Подписки между GitLab.com и Self-Managed не переносятся: при смене варианта поставки нужна новая подписка.

Эталонный .gitlab-ci.yml

Собранный пример для типового веб-проекта: сборка, тесты, публикация образа и деплой по защищённой ветке.

stages:
  - build
  - test
  - release
  - deploy

variables:
  IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA  # предопределённые переменные GitLab

default:
  image: node:22-alpine
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - .npm/    # ускоряем повторные установки зависимостей

build:
  stage: build
  script:
    - npm ci --cache .npm --prefer-offline
    - npm run build
  artifacts:
    paths:
      - dist/

test:
  stage: test
  script:
    - npm ci --cache .npm --prefer-offline
    - npm test -- --ci

release-image:
  stage: release
  image: docker:27
  services:
    - docker:27-dind
  script:
    # $CI_REGISTRY_USER и $CI_JOB_TOKEN выдаются пайплайну автоматически
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_JOB_TOKEN" "$CI_REGISTRY"
    - docker build -t "$IMAGE" .
    - docker push "$IMAGE"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-production:
  stage: deploy
  environment:
    name: production
    url: https://example.com
  script:
    # SSH_PRIVATE_KEY хранится в Settings → CI/CD → Variables как masked и protected
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
    - ./scripts/deploy.sh "$IMAGE"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      when: manual   # деплой запускается человеком

Практические сценарии

Статичный сайт или документация на GitLab Pages

Годится для лендинга, документации или прототипа: сборка и хостинг живут в одном проекте. GitLab публикует содержимое папки public из задания со свойством pages: true.

deploy-site:
  stage: deploy
  pages: true          # отмечает задание как публикацию Pages
  script:
    - npm ci
    - npm run build
    - mv dist public   # Pages по умолчанию берёт папку public
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Командный гейт: ничего не попадает в main без зелёного пайплайна

Минимум, который собирается даже на Free и заметно снижает число поломок в основной ветке:

1. Settings → Repository → Protected branches: защитите main, запретите прямой пуш и force push.
2. Settings → Merge requests: включите «Pipelines must succeed» и «All threads must be resolved».
3. В пайплайне добавьте правило if: $CI_PIPELINE_SOURCE == "merge_request_event", чтобы тесты шли на каждый MR.
4. Если нужны жёсткие правила утверждения (кто именно и сколько человек должны одобрить), понадобится Premium.

Код остаётся на GitHub, а сборка и зеркало — в GitLab

Зеркалирование настраивается в Settings → Repository → Mirroring repositories. Направление важно для тарифа:

• Push (из GitLab во внешний репозиторий) работает на всех тарифах, включая Free. Изменения доезжают до зеркала за пять минут, а с опцией «Only mirror protected branches» — за одну.
• Pull (из внешнего репозитория в GitLab) требует Premium или Ultimate. Именно этот режим нужен, если код живёт на GitHub, а пайплайны вы хотите вести в GitLab.

Ночные проверки по расписанию

Сканирование контейнеров, проверку ссылок или тяжёлые e2e-тесты лучше вынести из каждого пуша в ночной запуск. Расписание создаётся в Build → Pipeline schedules и доступно на всех тарифах, по умолчанию до 10 расписаний на проект.

nightly-e2e:
  stage: test
  script:
    - npm run test:e2e
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"   # только запуск по расписанию

Монорепозиторий: запускать только затронутые сервисы

Если фронтенд, API и инфраструктура лежат в одном репозитории, полный пайплайн на каждый коммит быстро съедает квоту. Ключ rules: changes запускает задание только при изменениях в нужных файлах.

test-api:
  stage: test
  script:
    - pytest services/api
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - services/api/**/*
        - requirements.txt

Пакеты и образы без внешнего реестра

Внутренние библиотеки можно публиковать в Package Registry того же проекта (npm, Maven, PyPI, Helm), а образы — в Container Registry. Авторизация внутри пайплайна идёт через $CI_JOB_TOKEN, поэтому отдельные токены и внешние сервисы для этого не нужны. Важный нюанс для бюджета: реестры и артефакты сборки не входят в лимит хранилища репозитория и LFS, но учитываются в общем расходе места намеспейса.

Проверка результата

Минимальный сценарий, который подтверждает, что связка работает:

1. Добавьте .gitlab-ci.yml из раздела «Первый пайплайн» и запушьте изменения в ветку.
2. Откройте Build → Pipelines. Новый пайплайн должен появиться в течение нескольких секунд со статусом running.
3. Дождитесь статуса passed у обеих задач. Лог каждой задачи открывается по клику и заканчивается строкой Job succeeded.
4. Проверьте, что артефакт сборки доступен: в задании build-job справа появляется блок Job artifacts с папкой dist/.
5. Откройте Settings → Usage Quotas → Pipelines и убедитесь, что расход compute-минут отражается в квоте. Если пайплайн выполнялся на своём раннере, расход остаётся нулевым.

Если пайплайн не запускается, проверьте три вещи: файл лежит в корне ветки, у вас роль Maintainer или Owner, для проекта доступен раннер с подходящими тегами.

Ограничения и когда не подходит

• Приватная команда больше пяти человек на Free. Лимит пяти участников касается именно приватных верхних групп, и обойти его на бесплатном тарифе нельзя. Для публичного open source ограничения нет, но сама экосистема внешних контрибьюторов вокруг GitHub плотнее.
• Экономия на бесплатном тарифе. 400 compute-минут расходуются быстро, поэтому для регулярных сборок нужен либо платный тариф, либо свой раннер.
• Нежелание администрировать. Self-Managed даёт полный контроль и требует обновлений, резервных копий и мониторинга. Если этих ресурсов нет, выбирайте облако.
• Только хранение кода. Для одного репозитория без автоматизации платформа избыточна: её ценность появляется, когда сборка, безопасность и деплой живут рядом с кодом.

Ссылки

• Сайт и тарифы: about.gitlab.com/pricing
• Документация: docs.gitlab.com
• Справочник синтаксиса CI/CD: docs.gitlab.com/ci/yaml
• Первый пайплайн, официальный туториал: docs.gitlab.com/ci/quick_start
• Установка раннера: docs.gitlab.com/runner/install
• Заметки о релизах: about.gitlab.com/whats-new

По теме

• Статья: Мой первый публичный репозиторий на GitHub — и это Codex-скилл для GPT Pro review
• Блог: GitHub предлагает забрать свой репозиторий на CD-ROM
• База знаний: GitHub для новичков — полное руководство: от регистрации до работы с Codex

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov