Dumper 1С: что это за инструмент и как он используется

Если вы встретили в вакансии, инструкции или разговоре коллег слово «dumper» применительно к 1С, речь почти наверняка идёт об утилите для выгрузки конфигурации 1С в набор текстовых файлов и обратной сборки конфигурации из этих файлов. Такой инструмент нужен, чтобы хранить код конфигурации в системе контроля версий (обычно Git), сравнивать изменения между релизами и автоматизировать сборку в CI/CD-конвейере.

Сам по себе «dumper» — не официальный продукт фирмы «1С», а общее название класса утилит. Наиболее известные реализации: обработка и скрипты на базе OneScript, инструменты из экосистемы vanessa-runner и oscript-library, а также штатный механизм конфигуратора «Выгрузить конфигурацию в файлы». Все они решают одну задачу: превратить бинарный файл конфигурации (CF) или базу данных в дерево файлов, понятное Git, и собрать его обратно.

Что такое dumper в контексте 1С

Слово «dump» в программировании означает снимок состояния: дамп памяти, дамп базы данных. В экосистеме 1С dumper — это программа, которая делает «снимок» конфигурации: разбирает её на составляющие (модули, формы, макеты, метаданные) и сохраняет каждую часть отдельным файлом в заданную папку.

Конфигурация 1С в «родном» виде — это либо файл с расширением .cf, либо набор таблиц внутри файловой или клиент-серверной информационной базы. Ни тот ни другой формат нельзя нормально сравнивать и версионировать: Git умеет показывать различия только в текстовых файлах. Dumper решает эту проблему, переводя конфигурацию в текстовое представление.

Обратная операция тоже поддерживается: из дерева файлов dumper собирает работоспособную конфигурацию и загружает её в базу. Благодаря этому цикл «изменил код → закоммитил → собрал → развернул на тестовой базе» становится полностью автоматизируемым.

Зачем нужна выгрузка конфигурации в файлы

Главная причина — командная разработка. Когда над конфигурацией работают несколько программистов, хранить её только в базе или в cf-файлах неудобно и рискованно: изменения перезаписывают друг друга, а понять, кто и что поменял, практически невозможно. Выгрузка в файлы даёт каждому разработчику возможность работать в своей ветке Git.

Вторая причина — история изменений и код-ревью. В репозитории видно каждую правку: какие строки модуля изменились, кем и когда. Перед слиянием ветки коллега может посмотреть diff и указать на ошибки — так же, как это делается в любой другой разработке.

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

Как работает типичный dumper

В основе большинства dumper-утилит лежит штатный механизм платформы 1С — пакетный режим конфигуратора. Конфигуратор запускается из командной строки с параметром /DumpConfigToFiles, который выгружает конфигурацию указанной базы в папку с файлами. Обратная операция выполняется параметром /LoadConfigFromFiles.

Dumper-скрипты оборачивают этот механизм в удобный интерфейс: принимают путь к базе, строку подключения или параметры сервера, сами формируют команду, обрабатывают ошибки и пишут журнал. Многие реализации написаны на OneScript — это открытый интерпретатор языка, похожего на встроенный язык 1С, который работает вне платформы.

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F"C:\Bases\DevBase" /N"Администратор" /DumpConfigToFiles "C:\Repo\src" -format Hierarchical

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

Чем dumper отличается от выгрузки в dt и cf

Файл .dt — это выгрузка всей информационной базы вместе с данными, а .cf — конфигурация без данных, но в бинарном виде. Оба формата нечитаемы для Git. Dumper работает именно с текстовым представлением конфигурации, поэтому он дополняет, а не заменяет регламентные выгрузки dt для резервного копирования.

Чем dumper отличается от EDT и хранилища конфигурации

У задачи версионирования в 1С есть несколько штатных решений, и dumper конкурирует с ними не напрямую, а как часть более широкого подхода.

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

Как настроить выгрузку конфигурации в Git через dumper

Базовый сценарий выглядит так: у каждого разработчика есть локальная база, а выгрузка в файлы выполняется перед коммитом. Ниже — типовой порядок действий, который подходит для большинства dumper-скриптов и для ручного запуска конфигуратора.

1. 1
   Установите платформу 1С нужной версии и, при необходимости, OneScript с выбранным dumper-пакетом
2. 2
   Создайте пустой Git-репозиторий и добавьте в .gitignore служебные файлы базы и временные каталоги
3. 3
   Выполните первичную выгрузку конфигурации в папку src внутри репозитория
4. 4
   Сделайте первый коммит — это базовая точка, от которой пойдёт история
5. 5
   Настройте скрипт или bat-файл, который одной командой выгружает конфигурацию из рабочей базы в src
6. 6
   Перед каждым коммитом запускайте выгрузку и проверяйте diff: в нём должны быть только ваши изменения
7. 7
   Для обратной проверки соберите конфигурацию из файлов в чистую пустую базу и убедитесь, что она загружается без ошибок

Ключевое правило: выгружать нужно всегда из одной и той же базы-источника, иначе в diff попадут чужие или устаревшие изменения. В командах обычно заводят отдельную «чистую» базу, в которую сначала загружают актуальную конфигурацию из репозитория, а уже из неё делают выгрузку.

Типичные ошибки и ограничения

Отдельно стоит помнить об ограничениях. Выгрузка в файлы не переносит данные информационной базы — только конфигурацию. Пользователи, роли с назначенными правами на конкретной базе, расширения и настройки хранилища в файлы не попадают. Для резервного копирования данных по-прежнему нужны выгрузки dt или средства СУБД.

Как проверить, что выгрузка и сборка работают корректно

Главный критерий корректности dumper-процесса — обратимость: конфигурация, собранная из файлов, должна совпадать с исходной. Проверяется это просто: выгрузите конфигурацию в файлы, соберите её в пустую базу, выгрузите повторно и сравните два дерева файлов. Различий быть не должно, кроме служебных меток времени.

FAQ