Как из одной конфигурации организовать формирование разных дистрибутивов для поставки клиентам?

При разработке тиражных решений на платформе «1С:Предприятие» разработчики часто сталкиваются с необходимостью выпуска нескольких версий одного и того же продукта. Например, это могут быть тарифные планы Lite (базовая версия с ограниченным набором функций), Standard (основная рабочая версия) и Corporate / КОРП (полнофункциональная версия для крупных клиентов).

Вести параллельную разработку нескольких схожих конфигураций в разных хранилищах крайне неэффективно: это приводит к дублированию кода, трудностям при переносе изменений и колоссальным временным затратам на тестирование и поддержку. Логичным решением кажется разработка одной «максимальной» конфигурации, из которой перед поставкой отсекается все лишнее. Однако стандартный механизм формирования файлов поставки в 1С не позволяет исключить отдельные объекты метаданных «на лету» без изменения самой конфигурации, а использование механизмов вроде ФункциональныеОпции не решает проблему физического присутствия закрытого кода в файле поставки .cf.

В этой статье мы подробно разберем, как решить эту задачу, объединив все наработки в одну конфигурацию и настроив процесс автоматизированной или полуавтоматической сборки различных вариантов дистрибутивов.

Метод 1. Автоматическая сборка через выгрузку в файлы и очистку скриптами (CI/CD подход)

Это наиболее надежный и современный способ, который можно полностью автоматизировать. Суть метода заключается в том, что полная конфигурация выгружается в XML-файлы, специальный скрипт удаляет файлы ненужных объектов и корректирует файлы описания конфигурации, после чего очищенная конфигурация собирается обратно в файл поставки .cf.

Выясним по шагам, как устроен этот процесс:

1. Выгрузка конфигурации-источника в файлы. С помощью CLI (интерфейса командной строки) конфигуратора 1С мы выгружаем структуру метаданных полной конфигурации в указанную директорию.
2. Физическое удаление файлов метаданных. Скрипт (написанный на OneScript, Python или PowerShell) удаляет папки конкретных отчетов, обработок или документов, которые не должны войти в текущую сборку (например, версию Lite).
3. Корректировка конфигурационных файлов. Скрипт парсит главный файл описания структуры Configuration.xml и удаляет из него ссылки на удаленные объекты метаданных, чтобы конфигуратор не выдал ошибку целостности при импорте.
4. Загрузка очищенной структуры во временную базу. Скрипт инициализирует пустую базу данных и загружает в нее измененные файлы конфигурации.
5. Генерация финального дистрибутива. Конфигуратор выгружает готовый файл .cf для конкретной поставки.

Рассмотрим пример реализации такого скрипта на языке OneScript (oscript.io), который автоматизирует рутинную очистку файлов выгрузки:

// Пример скрипта OneScript для удаления метаданных из выгрузки конфигурации
Перем ПутьКФайлам, ИмяОбъектаДляУдаления;

ПутьКФайлам = "C:\Build\SourceConfiguration\";
ИмяОбъектаДляУдаления = "Отчет.КорпоративныйАнализ";

// Шаг 1. Физическое удаление каталога объекта метаданных
КаталогОбъекта = Новый Файл(ПутьКФайлам + "Reports\" + ИмяОбъектаДляУдаления);
Если КаталогОбъекта.Существует() Тогда
    УдалитьФайлы(КаталогОбъекта.Путь);
    Сообщить("Файлы объекта " + ИмяОбъектаДляУдаления + " успешно удалены.");
КонецЕсли;

// Шаг 2. Корректировка Configuration.xml (упрощенный пример работы с XML)
ЧтениеXML = Новый ЧтениеXML;
ЧтениеXML.ОткрытьФайл(ПутьКФайлам + "Configuration.xml");

ДокументXML = Новый ДокументDOM;
Построитель = Новый ПостроительDOM;
ДокументXML = Построитель.Прочитать(ЧтениеXML);
ЧтениеXML.Закрыть();

// Поиск и удаление узла метаданных из описания конфигурации
УзлыОтчетов = ДокументXML.ПолучитьЭлементыПоИмени("Report");
Для Каждого Узел Из УзлыОтчетов Цикл
    Если Узел.ТекстовоеСодержимое = ИмяОбъектаДляУдаления Тогда
        Узел.РодительскийУзел.УдалитьДочерний(Узел);
        Прервать;
    КонецЕсли;
КонецЦикла;

// Сохранение измененного файла конфигурации
ЗаписьXML = Новый ЗаписьXML;
ЗаписьXML.ОткрытьФайл(ПутьКФайлам + "Configuration.xml");
ЗаписьDOM = Новый ЗаписьDOM;
ЗаписьDOM.Записать(ДокументXML, ЗаписьXML);
ЗаписьXML.Закрыть();

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

1cv8.exe DESIGNER /F "C:\Db\TempBase" /N "Администратор" /P "Пароль" /LoadConfigFromFiles "C:\Build\SourceConfiguration" /UpdateDBCfg

И следом выполняем команду для выгрузки готового файла поставки:

1cv8.exe DESIGNER /F "C:\Db\TempBase" /N "Администратор" /P "Пароль" /DumpCfg "C:\Build\Release\Lite_Version.cf"

Этот подход позволяет создать полностью автоматический конвейер (CI/CD пайплайн) в GitLab, GitHub или Jenkins, собирающий нужные версии дистрибутивов по нажатию одной кнопки.

Метод 2. Использование механизмов расширения конфигурации (Современный стандарт)

Если вы не хотите связываться с написанием скриптов разбора XML-файлов, проанализируем альтернативный архитектурный подход, который активно развивается в платформе 1С начиная с версии 8.3.15 — расширения конфигурации.

Вместо физического «вырезания» функционала из полной конфигурации, мы строим архитектуру решения от обратного:

• За основную конфигурацию принимается базовая версия продукта (Lite/Base). В ней содержится только общее ядро системы.
• Весь дополнительный функционал (специфические отчеты, сложные документы, интеграционные механизмы, КОРП-подсистемы) выносится в отдельные расширения конфигурации (файлы .cfe).
• Для клиентов базовой версии поставляется только основной файл .cf.
• Для клиентов продвинутых версий поставляется тот же файл .cf совместно с пакетом расширений .cfe, которые бесшовно дополняют интерфейс и логику системы.

Преимущества данного подхода: Полное отсутствие дублирования кода, легкая поддержка и обновление основной конфигурации (поставщиком), отсутствие необходимости декомпиляции структуры файлов при сборке.

Метод 3. Промежуточное объединение конфигураций (Visual-метод)

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

1. Создаем чистую базу данных (назовем ее «База сборки»).
2. Выгружаем файл полной конфигурации .cf из основного хранилища.
3. Загружаем этот .cf в «Базу сборки».
4. Вручную (или используя заранее подготовленный файл настроек объединения) удаляем ненужные объекты метаданных, руководствуясь подготовленным списком или принадлежностью объектов к определенным подсистемам.
5. Сохраняем конфигурацию и выгружаем результирующий файл поставки.

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

Важные правила разработки: как избежать «битых ссылок» при сборке

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

Чтобы избежать таких ситуаций, придерживайтесь следующих правил написания кода:

1. Отказ от статической типизации при обращении к опциональным объектам. Избегайте прямого написания типов удаляемых объектов в общих модулях базовой версии.
2. Динамическая проверка наличия метаданных. Перед выполнением кода, связанного с опциональными подсистемами, проверяйте их физическое наличие в метаданных текущей сборки:

ИмяДокумента = "Документ.КорпоративныйБюджет";
Если Метаданные.Документы.Найти(ИмяДокумента) <> Неопределено Тогда
    // Объект присутствует в текущей сборке (например, в КОРП-версии)
    ВыполнитьКодДинамически(ИмяДокумента);
КонецЕсли;

3. Использование безопасных вызовов через Выполнить() и Вычислить(). Выносите обращение к специфическим реквизитам и методам удаляемых объектов в динамически исполняемые строки кода:

// Безопасное создание документа без прямой привязки типов в конфигурации
ИмяДокумента = "КорпоративныйБюджет";
Если Метаданные.Документы.Найти(ИмяДокумента) <> Неопределено Тогда
    Выполнить("НовыйДок = Документы." + ИмяДокумента + ".СоздатьДокумент(); НовыйДок.Записать();");
КонецЕсли;

Использование этих несложных правил в сочетании с автоматизированной сборкой через OneScript позволит вам безболезненно сопровождать сложные тиражные программные продукты любой глубины кастомизации из одного единственного репозитория кода.