Как организовать систему контроля версий для внешних обработок и отчетов в 1С?

При активной разработке внешних обработок (.epf) и отчетов (.erf) неизбежно возникает задача безопасного сохранения истории изменений. Ручное создание множества папок и файлов с постфиксами дат и номеров версий приводит к путанице, засорению дискового пространства и невозможности быстро восстановить работоспособную версию в случае сбоя. Рассмотрим, как правильно выстроить процесс версионирования внешних разработок с использованием современных инструментов и штатных возможностей платформы 1С.

В чем сложность контроля версий для файлов EPF и ERF

Проанализируем специфику формата внешних файлов 1С. Файлы с расширениями .epf и .erf представляют собой бинарные контейнеры платформы. По этой причине возникают следующие технические нюансы:

1. Отсутствие стандартного построчного сравнения: классические системы контроля версий (Git, SVN, Mercurial) воспринимают бинарный файл как единое целое и не могут отобразить дифференциал строк (diff) между коммитами без дополнительных утилит.
2. Разрастание репозитория: при каждом коммите сохраняется копия бинарного файла целиком, что быстро увеличивает размер локального и удаленного хранилища.
3. Сложности параллельной разработки: автоматическое слияние веток (merge) бинарных файлов невозможно, требуется ручное разрешение конфликтов.

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

Вариант 1. Хранение бинарных файлов в Git или SVN с визуальным сравнением в Конфигураторе

Разберем самый простой и быстрый в развертывании подход. Он не требует предварительной настройки скриптов сборки-разборки и подходит для небольших команд или индивидуальной разработки.

1. Создаем локальный репозиторий Git или SVN в рабочей директории с обработками.
2. Для управления версиями и ветками подключаем графический клиент (например, SourceTree, TortoiseGit или TortoiseSVN) и связываем его с удаленным репозиторием на GitLab, Bitbucket или GitHub.
3. Фиксируем изменения после каждого этапа доработки с понятными комментариями. Это гарантирует возможность откатиться к любой исторической точке.
4. Для сравнения текущей версии со старыми ревизиями извлекаем нужный коммит во временный каталог и выполняем штатное сравнение в Конфигураторе 1С через меню Файл -> Сравнить файлы.... Платформа сопоставит структуру метаданных, реквизиты, формы и модули.

Совет: чтобы репозиторий не разрастался из-за бинарных файлов, для Git рекомендуется подключить механизм Git LFS (Large File Storage).

Вариант 2. Разборка файлов в текстовые исходники и сборка через хуки

Рассмотрим более продвинутый подход, приближающий разработку на 1С к классической разработке ПО. Платформа 1С:Предприятие поддерживает выгрузку внешних обработок и отчетов в набор XML-файлов и модулей кода с последующей обратной сборкой.

Для автоматизации этой процедуры используются параметры пакетного запуска Конфигуратора:

1. /DumpExternalDataProcessorOrReportToFiles — распаковывает бинарный файл обработки в каталог с текстовыми файлами исходников.
2. /LoadExternalDataProcessorOrReportToFiles — собирает исполняемый файл .epf из набора исходных текстов.

Посмотрим на пример пакетной команды для разборки внешней обработки на исходники:

"C:\Program Files\1cv8\8.3.23.1688\bin\1cv8.exe" DESIGNER /IBConnectionString "File=C:\1C_Bases\DevBase;" /DumpExternalDataProcessorOrReportToFiles "C:\Repo\Source\MyProcessor" "C:\Repo\Bin\MyProcessor.epf"

Пример обратной сборки файла обработки перед тестированием или релизом:

"C:\Program Files\1cv8\8.3.23.1688\bin\1cv8.exe" DESIGNER /IBConnectionString "File=C:\1C_Bases\DevBase;" /LoadExternalDataProcessorOrReportToFiles "C:\Repo\Bin\MyProcessor.epf" "C:\Repo\Source\MyProcessor"

Чтобы автоматизировать этот процесс, настраивают специализированные pre-commit хуки (например, инструмент precommit1c). При попытке сделать коммит скрипт автоматически декомпилирует измененный .epf в исходные файлы, и в историю репозитория попадает чистый читаемый текст модулей. Это позволяет просматривать историю изменений кода в интерфейсе GitLab/GitHub и проводить полноценное код-ревью.

Вариант 3. Использование среды разработки 1С:EDT

Если разработка ведется в специализированной среде 1С:Enterprise Development Tools (1С:EDT), задача решается штатно. В этой среде проект внешней обработки изначально хранится в виде структурированного каталога с текстовыми файлами. Встроенная поддержка Git позволяет выполнять фиксацию изменений, ветвление, слияние и визуальный просмотр различий непосредственно из интерфейса среды разработки без необходимости настраивать сторонние скрипты разборки.

Вариант 4. Версионирование внутри информационной базы средствами БСП

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

1. Открываем подсистему Дополнительные отчеты и обработки (входит в состав Библиотеки стандартных подсистем — БСП, а также типовых конфигураций ERP, КА, УТ, ЗУП, Бухгалтерия предприятия).
2. Включаем подсистему Версионирование объектов для справочника ДополнительныеОтчетыИОбработки.
3. При загрузке новой версии файла платформа автоматически сохраняет предыдущую ревизию с указанием автора, комментария и даты изменения. При необходимости администратор может в любой момент выгрузить из базы или активировать ранее сохраненную версию.

Выбор конкретного решения зависит от масштаба команды: для индивидуальной разработки достаточно Git с визуальным клиентом и сравнением через Конфигуратор, а для командной работы рекомендуется настроить версионирование исходного кода с помощью пакетной выгрузки или среды 1С:EDT.