GitLab: репозиторий, merge request, CI/CD и эксплуатация

GitLab — платформа вокруг Git-репозиториев. Она хранит код, управляет доступом, связывает изменения с задачами и merge request, запускает CI/CD и показывает состояние развёртываний. Git при этом остаётся отдельной системой: commit, ветка и merge существуют локально даже без GitLab.

Польза GitLab появляется не от самого переноса репозитория. Платформа становится центром инженерного процесса, когда команда определяет правила review, изолирует runners, защищает секреты и умеет восстановить данные. Без этого единый интерфейс лишь собирает риски в одном месте.

Из чего состоит проект

Project — контейнер для репозитория и связанных функций. В нём могут находиться issues, wiki, packages, container registry, pipelines, environments и настройки прав. Group объединяет проекты и позволяет наследовать часть политик.

Git-репозиторий хранит историю файлов и ссылки на ветки и теги. Issue описывает задачу или дефект. Merge request, сокращённо MR, предлагает слить одну ветку в другую и служит местом review: обсуждения diff, автоматических проверок и решения о merge.

Это разные объекты. Закрытие issue не меняет код само по себе, зелёный pipeline не доказывает качество архитектуры, а merge request не является резервной копией рабочей среды.

Рабочий цикл изменения

Разработчик получает репозиторий, создаёт ветку, делает небольшие осмысленные commits и отправляет ветку на сервер. Затем открывает MR в защищённую основную ветку.

Хороший MR сообщает:

• какую проблему решает;
• почему выбран этот подход;
• как проверить результат;
• меняются ли данные, API или конфигурация;
• как откатить выпуск;
• какие риски остаются.

Reviewer читает не только diff. Он проверяет контракт, тесты, обработку ошибок, безопасность миграций и наблюдаемость. Автоматические правила могут требовать успешный pipeline и определённое число approvals, но не заменяют инженерного суждения.

Стратегию merge выбирают осознанно. Merge commit сохраняет ветвление, squash собирает изменения MR в один commit, rebase переписывает commits поверх новой базы. Подробно различия разобраны в статье про merge и rebase.

Права и защищённые ветки

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

Основную ветку защищают от прямого push и force-push. Изменения проходят через MR, review и pipeline. Теги релизов тоже стоит защищать, иначе пользователь с правом записи сможет заменить ссылку, по которой автоматизация выбирает код для production.

Особое внимание — токенам:

• personal access token действует от имени пользователя;
• project/group access token удобнее для сервисной интеграции с ограниченной областью;
• deploy key даёт SSH-доступ к репозиторию;
• deploy token применяется к registry и репозиторию в предусмотренных сценариях;
• CI job token имеет контекст задания и собственную модель разрешений.

Не используйте личный бессрочный token в общей автоматизации. Ограничьте scopes, задайте срок, храните владельца интеграции и процедуру ротации. Утечка токена требует отзыва, а не только удаления строки из последнего commit: секрет остаётся в истории и журналах.

Pipeline и job

Pipeline — граф автоматических заданий. Stage задаёт укрупнённый порядок, job описывает конкретную проверку или действие. Конфигурация обычно хранится в .gitlab-ci.yml рядом с кодом, поэтому её изменение проходит review.

Минимальный пример для Node.js-проекта запускает установку зависимостей и тесты. Команды выполняются не на ноутбуке автора, а внутри окружения runner:

stages:
  - test

unit-tests:
  stage: test
  image: node:24-alpine
  script:
    - npm ci
    - npm test
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Здесь image выбирает контейнер исполнения, npm ci устанавливает версии из lock-файла, а rules ограничивает job pipelines для MR. Тег образа в реальном проекте фиксируют согласно политике обновлений; плавающий тег способен изменить среду без изменения репозитория.

Успех — pipeline завершился, тесты действительно были обнаружены, а job не скрыла ошибку конструкцией вроде || true. При сбое изучите лог первой содержательной ошибки, а не последнюю строку cleanup.

Runner исполняет недоверенный код

GitLab Runner получает job и запускает её через executor: shell, Docker, Kubernetes или другой поддерживаемый вариант. Это граница безопасности. Код из ветки способен читать всё, что доступно процессу job.

Shell runner на постоянном сервере особенно чувствителен: задания делят файловую систему и возможности хоста. Изолированный контейнер уменьшает часть рисков, но сокет Docker, привилегированный режим и host mounts снова дают широкий доступ.

Не передавайте production-секреты pipelines из непроверенных веток. Защищённые variables должны попадать только в защищённые refs, а fork и внешние contributors требуют отдельной модели. Маскирование скрывает подходящую строку в UI, но не делает секрет безопасным для вредоносного скрипта.

Runner следует обновлять, ограничивать тегами и привязывать к ожидаемым проектам. Кэш ускоряет сборку, но не должен переносить credentials и результаты между недоверенными контекстами.

Artifacts, cache и registry

Cache ускоряет повторную работу, например загрузку зависимостей. Он может исчезнуть и не является результатом, на котором строится корректность.

Artifact — файл конкретного job: отчёт тестов, собранный пакет, coverage. У него есть срок хранения и права доступа. Container Registry хранит образы. Один и тот же проверенный artifact лучше продвигать между средами, чем пересобирать production отдельно из той же ветки: повторная сборка способна получить другие зависимости.

Тег latest не идентифицирует содержимое. Для развёртывания используйте digest или неизменяемый тег, связанный с commit. Подписывание и SBOM дополняют, но не отменяют контроль источников и runner.

Environments и deployments

Environment представляет целевую среду: review, staging, production. Deployment связывает job, commit и время изменения. Это полезный журнал, но он точен только если все изменения проходят через GitLab. Ручная правка production создаёт drift — фактическое состояние расходится с записанным.

Production job ограничивают защищённой веткой и, при необходимости, ручным подтверждением. Подтверждение должно быть проверкой риска, а не кнопкой, которую нажимают автоматически. Для опасной миграции нужны совместимость версий и отдельный план возврата.

CI/CD описывает общий процесс; практические проверки рассмотрены в статье что такое CI/CD и проверки Git перед публикацией.

GitLab.com или self-managed

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

Self-managed устанавливается в собственной инфраструктуре и даёт контроль над сетью, хранением и интеграциями. Вместе с контролем команда получает обязанности:

• планировать обновления и читать breaking changes;
• резервировать PostgreSQL, repositories, uploads, registry и конфигурацию;
• мониторить фоновые очереди, диски и сертификаты;
• управлять почтой, DNS, runners и object storage;
• проверять восстановление;
• защищать административный доступ.

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

Резервная копия должна восстанавливаться

Штатный backup GitLab и экспорт проекта решают разные задачи. Экспорт помогает переносить поддерживаемую часть проекта. Полное восстановление экземпляра требует совместимых версий, данных приложения, secrets-конфигурации и внешних хранилищ.

Container Registry, object storage и конфигурационные secrets могут резервироваться отдельным способом. Реплика базы повышает доступность, но не заменяет backup: ошибочное удаление и повреждение логически реплицируются.

Проверка backup — восстановление в изолированной среде, вход, чтение репозитория, запуск ключевой функции и фиксация времени. Без такой проверки известен размер архива, но не результат.

Наблюдаемость и обслуживание

Для self-managed следите за свободным диском и inode, состоянием PostgreSQL и Redis, очередью Sidekiq, задержкой Gitaly, ошибками web, длительностью backup и сроками сертификатов. Рост pipeline может упереться не в GitLab, а в нехватку runners.

Не храните бесконечно artifacts, registry-теги и журналы. Политика retention должна учитывать расследования и воспроизводимость релизов. Удаление выполняйте штатными механизмами и сначала проверяйте, какие releases ещё используют образы.

Когда GitLab подходит

GitLab удобен команде, которая хочет связать репозитории, review, automation и deployments в одной модели прав. Он особенно полезен, когда важны self-managed размещение и глубокая интеграция встроенных функций.

GitHub, Bitbucket и специализированный набор сервисов решают похожие задачи иначе. Миграционная стоимость включает не только Git-историю, но и issues, packages, CI-конфигурацию, secrets, permissions и привычки команды. Начинайте выбор с процесса и рисков, а не с количества пунктов в таблице.

Источники

• GitLab: project repository
• GitLab: CI/CD
• GitLab: runners
• GitLab: backup and restore