Git по-нашему: как и зачем мы сделали собственный инструмент многопоточной разработки

Руководитель проектов ALP Group Егор Сорокин делится личным опытом создания обработок Gitflow Tools на языке 1С.

Ни для кого не секрет, что параллельная коллективная разработка намного эффективнее, нежели последовательная. Многие крупные ИТ-компании, желая достичь преимуществ одномоментной разработки, со скрипом переходили на DevOps-методологии, открывали целые департаменты для набора соответствующих специалистов и пытались — с переменным успехом — сделать закостенелый процесс более гибким и контролируемым.

В какой-то момент, достигнув определенных бизнес-масштабов, ALP Group тоже столкнулась с необходимостью хранить изменения обособленно и вести быструю разработку большим числом разработчиков. Для решения этой задачи нужно было погрузиться в устройство классической системы управления версиями Git и понять, как интегрировать ее с 1С, на продуктах которой завязано большинство наших проектов.

Хотя первая версия Git была выпущена еще в 2005 году, по ощущениям, до сих пор лишь небольшая доля команд разработчиков 1С использует Git на постоянной основе. Это довольно сложный набор утилит командной строки с параметрами. Чтобы подключить Git к 1С, необходимо выполнить установку дополнительного программного обеспечения, подключиться к репозиторию, завести аккаунт на одном из хостингов, всё корректно настроить и разобраться в специфике работы с консолью GitBash. Всё это требует большого профессионального уровня погружения разработчиков в специфику Git, а главное — свободного времени и горящих глаз для изучения чего-то нового. С горящими глазами у нас проблем не было, а вот со временем, на фоне других срочных задач, — были.

Тогда мы решили оценить второй вариант: работать с Git не напрямую, а через специальное решение вендора — “1С:Enterprise Development Tools”. “1C:EDT” — это расширяемая среда разработки прикладных решений, уже интегрированная с Git. По сути, “1C:EDT” — навороченный аналог знакомого всем конфигуратора. Не возьмусь оценить последнюю версию решения, но на тот момент, когда мы заинтересовались средой EDT, она подтормаживала, долго запускала проект, иногда теряла доработки и в довесок имела немало багов.

От бессилия хотелось отказаться от этой идеи и вернуться к разработке в привычном конфигураторе. Но в IT, кто не учится — тот теряет клиентов и деньги. В итоге мы решили действовать самостоятельно и создать собственный инструмент многопоточной разработки.

Мы хотели сделать максимально простое и изящное решение без лишних (конкретно для наших проектов) фич. Так было создано две обработки на языке 1С, о которых я расскажу ниже.

1. Рабочее место разработчика (РМР).

Инструмент представляет из себя упрощенный Git-клиент в виде 1C-обработки. Под капотом решения — смесь из языков 1С, OneScript и прямых Git-команд. Как видно на скриншоте, у РМР всего две базовые кнопки — «Начать/продолжить работу» и «Поместить в удаленный репозиторий». Они реализуют два основных сценария работы:

а) Программист хочет начать работу над задачей. В этом случае он выбирает из списка уже существующую feature-ветку (либо указывает, что нужно создать новую) и нажимает кнопку «Начать/продолжить работу». В результате выполняется подготовка конфигурации к работе — создание новой ветки (либо переключение на уже существующую и синхронизация ее с удаленным репозиторием) и загрузка ветки в конфигуратор.

б) Программист хочет зафиксировать результат своей работы. В этом случае он нажимает кнопку «Поместить в удаленный репозиторий». Происходит выгрузка конфигурации в локальный Git-репозиторий, фиксация и отправка в удаленный репозиторий. Перед отправкой программисту будет показано окно с выполненными изменениями в KDiff (проверка на отсутствие случайных изменений).

Для выполнения всего вышеперечисленного программисту не нужно изучать команды Git, всё делается автоматически — нужные команды зашиты внутри РМР.

Остальные кнопки отвечают за вспомогательную функциональность.

2. Создание релизов.

Эта обработка загружает список обращений, еще не включенных в релиз, и выполняет сборку релиза из выбранных обращений. Решение позволяет изменить номер версии конфигураций прямо в окне сборки, не запуская конфигуратор. В случае если несколько обращений не получилось включить в релиз из-за конфликтов слияния, они откладываются в отдельный список, по которому можно впоследствии пройтись и включить обращения в релиз уже при помощи инструмента разрешения конфликтов (конфигуратор + CF или git-mergetool). Сборка из 5–10 мелких и средних задач без конфликтов слияния займет около 10 минут.

Так, с помощью двух простых обработок, мы реализовали многопоточную среду разработки, не потратив времени специалистов на изучение всех тонкостей Git-команд (эта участь выпала только на архитектора, который занимался обработками). При этом все преимущества системы Git теперь с нами: это и эффективное управление версиями кода, и отслеживание изменений, и возвращение к предыдущим версиям при необходимости, и возможность ветвления/слияния, и стабильность кодовой базы, и общее повышение производительности и качества разработки.

А как вы работаете с Git в 1С? Пожалуйста, поделитесь своим опытом в комментариях ⬇