Многопоточная разработка: как работать с Git в 1С

Преимущества многопоточной разработки с помощью Git

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

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

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

Обработки GitFlow Tools

Однако полноценная интеграция — не единственный способ работы с Git в 1С. Ниже я расскажу об альтернативном решении — двух простых самописных обработках на языке 1С.

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

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

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

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

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

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

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

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

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