← На главную

В сообществе 1С часто возникает вопрос: можно ли использовать GitLab не просто как систему контроля версий (Git), а как полноценный инструмент для управления всем циклом разработки, заменяя такие системы, как Jira? Давайте разберемся в этом вопросе, проанализируем опыт коллег и рассмотрим современные подходы к организации DevOps в экосистеме 1С.

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

Ограничения GitLab для управления задачами

Первое, с чем сталкиваются команды — это функционал ведения задач (Issues) в GitLab. Участники обсуждения сходятся во мнении, что в бесплатной версии (CE) он довольно урезан по сравнению со специализированными системами.

Ключевые моменты, на которые стоит обратить внимание:

• Базовый функционал: В GitLab можно создавать задачи, назначать исполнителей, ставить метки и отслеживать их на досках (Issue Boards). Однако для сложного планирования, ведения бэклога, создания эпиков и пользовательских историй часто требуется функционал, доступный только в платных версиях или в специализированных продуктах.
• Привычные связки: Большинство опытных команд приходят к выводу, что наиболее эффективной является связка из нескольких инструментов. Каждый инструмент решает свою задачу лучше всего. Популярные и проверенные временем комбинации:
  • GitLab + Jira: Классическая связка, где GitLab отвечает за код и CI/CD, а Jira — за управление проектом, задачами и методологиями (Scrum, Kanban).
  • GitLab + Redmine + Jenkins: Еще один рабочий вариант. Redmine выступает в роли системы управления задачами, Jenkins — как сервер для автоматизации сборок и развертывания, а GitLab — как центральный репозиторий кода.
• Идеология DevOps: Важно понимать, что в мире DevOps подход "всё в одном" не всегда является лучшим. Идеология заключается в использовании атомарных, специализированных инструментов, которые отлично выполняют свою функцию и легко интегрируются друг с другом. Это позволяет гибко настраивать процессы и заменять один компонент на другой без разрушения всей системы.

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

Правильное хранение кода 1С в GitLab

Самое большое заблуждение — это хранить в Git бинарные файлы конфигурации (.cf, .epf, .erf). Git не может анализировать их содержимое, и каждое изменение будет выглядеть как полная замена файла. Это лишает систему контроля версий ее главного преимущества — возможности видеть, что именно изменилось.

Правильный подход — хранить исходный код в текстовом формате. Рассмотрим, как это реализовать:

1. Для классического Конфигуратора: Необходимо выгружать конфигурацию в иерархическую структуру файлов XML и BSL (исходный код модулей). Для автоматизации этого процесса используются специальные инструменты, например, Gitsync или скрипты на OneScript. Эти скрипты перед каждым коммитом (отправкой в GitLab) разбирают бинарный файл на исходники. Это позволяет отслеживать изменения в каждом конкретном модуле, форме или объекте метаданных.
2. Для 1C:EDT (Enterprise Development Tools): Здесь все гораздо проще. EDT — это современная среда разработки на базе Eclipse, которая изначально хранит весь проект в виде файловой структуры. Интеграция с Git (и, соответственно, с GitLab) является нативной и не требует никаких дополнительных инструментов для конвертации. Вы работаете с кодом так же, как разработчики на Java или Python.

Главное преимущество: Когда код хранится в текстовом формате, вы получаете возможность проводить Code Review и видеть разницу (diff) между версиями прямо в веб-интерфейсе GitLab.

Мощь GitLab: Code Review и процесс Merge Requests

Это одна из самых сильных сторон GitLab, которая кардинально меняет культуру разработки в 1С. Вместо того чтобы разработчики напрямую вносили изменения в общее хранилище конфигурации, внедряется процесс Merge Requests (MR) или Pull Requests (PR).

Процесс выглядит следующим образом:

1. Создание ветки: Разработчик не работает в основной ветке (например, develop). Для каждой задачи он создает отдельную ветку (например, feature/TASK-123-new-report).
2. Работа над задачей: Все изменения по задаче делаются в этой изолированной ветке.
3. Создание Merge Request: Когда работа завершена, разработчик не сливает свой код в основную ветку, а создает Merge Request в GitLab. Это запрос на слияние его ветки с основной.
4. Code Review: Ведущий разработчик или коллеги получают уведомление. В веб-интерфейсе GitLab они видят все изменения, которые были сделаны, построчно. Они могут оставлять комментарии прямо к конкретным строкам кода, задавать вопросы и предлагать улучшения.
5. Утверждение и слияние: Только после того, как все замечания устранены и код получил одобрение (Approve), он сливается с основной веткой. Это слияние может запускать автоматические процессы, о которых мы поговорим ниже.

Такой подход значительно повышает качество кода, обеспечивает обмен знаниями в команде и снижает количество ошибок, попадающих в рабочую систему.

Автоматизация процессов с GitLab CI/CD

Хотя в обсуждении упоминался Jenkins, современный GitLab имеет мощный встроенный инструмент для автоматизации — GitLab CI/CD. Он позволяет отказаться от поддержки отдельного сервера Jenkins и описывать все шаги автоматизации в одном файле .gitlab-ci.yml, который хранится вместе с кодом.

С помощью GitLab Runner (агентов, которые выполняют задания) и OneScript можно автоматизировать практически весь цикл поставки ПО 1С:

Рассмотрим примерный сценарий (пайплайн), который запускается при создании Merge Request или слиянии в основную ветку:

• Синтаксический контроль: Автоматическая проверка всего измененного кода на наличие синтаксических ошибок.
• Статический анализ кода (Линтинг): Проверка кода на соответствие стандартам разработки с помощью инструментов вроде BSL Language Server. Это помогает поддерживать единый стиль кода во всей команде.
• Аудит кода на уязвимости: Интеграция с системами анализа качества кода, такими как SonarQube. GitLab может отправлять код на анализ, и если будут найдены критические ошибки или уязвимости, Merge Request будет автоматически заблокирован до их исправления.
• Автоматическое тестирование: Запуск сценарных тестов, написанных с помощью Vanessa-Automation. GitLab CI/CD может развернуть тестовую базу, выполнить тесты и предоставить отчет.
• Сборка дистрибутива: Автоматическая сборка файлов поставки (.cf, .cfu) из исходного кода.
• Развертывание на тестовом стенде: Автоматическая публикация собранной конфигурации на тестовом сервере для проверки тестировщиками или заказчиком.

Более того, результаты тестирования можно визуализировать. Например, при использовании Vanessa-Automation можно настроить выгрузку отчетов в формате Allure и их публикацию на GitLab Pages. Это дает красивые и интерактивные отчеты о прохождении тестов прямо в интерфейсе GitLab.

Альтернативы "Все в одном"

Для тех, кто ищет "комплексный обед от одного повара", как выразился один из участников форума, существует альтернатива. Главным конкурентом GitLab в этой нише является Azure DevOps (ранее известный как TFS).

Azure DevOps исторически предоставляет более тесно интегрированный набор инструментов:

• Azure Boards: Мощный аналог Jira для управления задачами (Work Items), бэклогом, спринтами.
• Azure Repos: Полноценная система контроля версий (поддерживает Git и TFVC).
• Azure Pipelines: Продвинутый аналог GitLab CI/CD для автоматизации сборок и развертывания.

Однако стоит отметить, что GitLab активно развивает свои инструменты управления проектами. В платных версиях появляются продвинутые доски задач, эпики и другие функции, которые приближают его к Jira и Azure DevOps, делая связку "только GitLab" все более реальной даже для средних команд.

Итог

Использовать GitLab при разработке в 1С не просто можно, а нужно. Он является ядром современного DevOps-процесса. Однако не стоит ожидать, что он в одиночку закроет все потребности.

Краткие выводы:

1. Для контроля версий и Code Review GitLab — идеальный инструмент, при условии, что вы храните исходники в текстовом виде (через EDT или выгрузку).
2. Для автоматизации (CI/CD) встроенный функционал GitLab CI/CD является мощной и удобной альтернативой Jenkins.
3. Для управления задачами и проектом GitLab в бесплатной версии может быть недостаточен. Оптимальным решением для большинства команд будет его интеграция с Jira или Redmine.

Внедрение GitLab и связанных с ним практик, таких как Merge Requests и CI/CD, — это не просто смена инструмента, а качественный скачок в культуре разработки, который приводит к повышению надежности и скорости выпуска продукта.