GitLab

Основная информация

GitLab — это система контроля версий, в которой хранятся не только исходные коды проектов, но и комментарии к ним. У каждого проектного менеджера есть своя группа, в рамках которой им создаются проекты. Важно соблюдать правильную структуру репозитория. Для различных направлений разработки (backend, frontend, qa) создаются отдельные папки, в которых хранятся файлы, документы и конфигурации, необходимые для запуска проекта.

Структура репозитория. Основные файлы и их назначение

• .env.example — пример файла конфигурации, содержащий настройки, такие как порты, параметры S3 и другие переменные окружения.

  ! Важно: значения из .env.example не должны использоваться на продакшене — это критично для безопасности. Перед деплоем необходимо подставлять корректные значения.

• .gitignore — список файлов и директорий, которые не должны загружаться в репозиторий (например, временные файлы, зависимости, артефакты сборки).

• .gitlab-ci.yml — файл конфигурации CI/CD, который определяет автоматическое тестирование, развертывание и сборку проекта.

  Включает в себя:

  • build — этап упаковки кода в приложение.

  • test — запуск юнит- и интеграционных тестов.

  • deploy — деплой проекта на сервер с полной пересборкой.

  • endtoend — тестирование сквозных (end-to-end) сценариев, проверяющих работоспособность системы в целом.

• docker-compose.yml — файл конфигурации для развертывания проекта в docker-контейнерах.

• start.sh — скрипт для запуска проекта.

• README.md — документация проекта, включающая инструкцию по запуску, настройке и работе с кодом.

Ветки

Вся разработка ведётся в ветках, которые отображают текущее состояние проекта. Каждый круглый значок на схеме — это коммит, который фиксирует состояние файлов в репозитории (кодовую базу). Любое изменение, внесенное разработчиком, отмечается коммитом, а стрелки указывают порядок переноса кода между ветками.

Что важно знать о ветках:

• Ветка — это указатель на текущее состояние проекта.

• dev → test → stage → main — код должен проходить этот путь, за его соблюдением нужно следить.

• Ветки должны оставаться актуальными, устаревшие ветки необходимо удалять.

• Разработчики создают новые ветки от dev, работают в них, затем отправляют код в GitLab и выполняют merge обратно в dev.

• Каждый разработчик должен работать в отдельной ветке, чтобы избежать конфликтов в коде.

• Пушить код напрямую в dev нельзя.

• Ветки важно называть номером задачи из Leantime (пример #3952).

Protected branches

GitLab поддерживает систему ветвления, которая включает четыре уровня (контуры) разработки (test, dev, main, stage). В разделе “Protected branches” устанавливаются разрешения на использование веток.

• Allowed to merge- указывается роль, которой разрешено выполнять слияние кода. Мы указываем - Maintainers

• Allowed to push and merge- разрешение на пуш и слияние. Мы указываем - No one.

• Allowed to force push- возможность изменять старые коммиты (должна быть выключена, за исключением экстренных случаев исправления ошибок).

Manage-members

В данном разделе GitLab мы добавляем участников и выдаем им роли

• Guest, Planner, Reporter обычно никому не назначается

• Maintainer- выдается тому кто будет делать merge и следит за репозиторием

• Developer- выдается разработчикам

• Owner- IT дирекция, PM

Pipelines

Pipelines- это раздел в GitLab, где отслеживается процесс выполнения кода. Здесь автоматически запускаются этапы развертывания, тестирования, сборки и другие процессы, необходимые для контроля качества проекта.

! Важно: следить за состоянием Pipelines, так как они показывают успешность выполнения задач:

✅ Зеленая галочка — все этапы выполнены успешно, код работает корректно.

❌ Красная ошибка — произошел сбой, требуется исправление

Fast-forward merges

Fast-forward merge должен быть включен, это помогает поддерживать чистую историю коммитов, снижает вероятность конфликтов и упрощает чтение логов.

Инструкция для включения:

• Settings → Merge requests

• Merge requests

• Включить опцию "Only allow fast-forward merges"

• Сохранить изменения