Как организовать разработку базовой и расширенной конфигураций на единой кодовой базе в 1С?

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

Разберем основные архитектурные и технические подходы, которые позволяют организовать разработку нескольких продуктов на базе единого исходного кода в среде 1С:Предприятие 8.

Подход 1. Автоматизированная нарезка из мастер-конфигурации (подход фирмы «1С»)

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

Рассмотрим, как устроен этот процесс:

1. Разметка подсистемами: Все объекты метаданных распределяются по иерархическим подсистемам. Например, подсистемы производства, сложного бюджетирования или регламентированного учета включаются только в состав старшей конфигурации.
2. Специальные маркеры в коде: Встроенный язык 1С не имеет пользовательских директив препроцессора (таких как #Если КОРП). Поэтому в текстах модулей используются служебные комментарии-теги для внешнего парсера исходного кода.
3. Декомпозиция исходников: Конфигурация выгружается в файлы XML (через стандартную выгрузку конфигурации в файлы или формат 1C:Enterprise Development Tools — EDT).
4. Обработка сборочным скриптом: Скрипт сборки на основе конфигурационного файла релиза удаляет каталоги неиспользуемых метаданных, вырезает размеченные блоки кода из файлов модулей, очищает состав ролей и подсистем.
5. Сборка результирующего .cf: Очищенные исходные тексты загружаются в эталонную базу пакетным запуском конфигуратора или утилитами сборки платформы для формирования дистрибутива поставки.

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

Посмотрим, как выглядит пример разметки кода специальными комментариями для внешнего препроцессора сборки:

// В коде общего модуля размещаются маркеры для сборочного скрипта
Функция ПолучитьПараметрыРасчета() Экспорт

    Параметры = Новый Структура;
    Параметры.Вставить("БазовыйТариф", 100);

    // &НачалоВставки(КОРП)
    Параметры.Вставить("РасширеннаяАналитика", Истина);
    Параметры.Вставить("КоэффициентСложности", 1.5);
    // &КонецВставки(КОРП)

    Возврат Параметры;

КонецФункции

Подход 2. Использование функциональных опций (ФО)

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

Разберем по шагам схему реализации:

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

Рассмотрим пример проверки доступности опции в программном модуле:

Если ПолучитьФункциональнуюОпцию("ИспользоватьРасширенныйФункционал") Тогда
    // Выполняем алгоритмы старшей редакции
    ВыполнитьРасширенныйРасчет();
Иначе
    // Выполняем базовый алгоритм
    ВыполнитьБазовыйРасчет();
КонецЕсли;

Подход 3. Архитектура «Базовая конфигурация + Расширение (.cfe)»

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

Рассмотрим ключевые особенности этой архитектуры:

1. Основная конфигурация (.cf): Содержит все общее ядро, базовые справочники, документы и типовую бизнес-логику. Она поставляется как младшая редакция продукта.
2. Расширение конфигурации (.cfe): Создается с назначением Адаптация или Дополнение. В него выносятся специфические объекты метаданных старшей версии, дополнительные реквизиты к объектам ядра и переопределения логики с помощью аннотаций &Вместо, &После или &Перед.
3. Обновление и сопровождение: Базовая конфигурация обновляется стандартными файлами поставки, не затрагивая расширенный функционал, что существенно снижает трудозатраты на сопровождение.

Подход 4. Ветвление в системе контроля версий (Git / EDT)

Если разработка ведется в 1C:Enterprise Development Tools или конфигурация выгружается в Git, организуем процесс через модель ветвления:

1. Создается основная ветка ядра main-core, в которой ведется разработка только базовой функциональности младшей конфигурации.
2. От нее создается ветка corp-release для старшей версии.
3. Все исправления и базовые доработки выполняются строго в ветке main-core и регулярно переносятся в ветку corp-release через стандартные операции слияния (merge).
4. Специфичный для старшей версии код добавляется непосредственно в ветку corp-release и никогда не вливается обратно в ядро.

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