В среде разработчиков 1С полное снятие конфигурации с поддержки (отвязка от конфигурации поставщика) часто воспринимается как признак непрофессионализма. Однако существуют специфические сценарии и технические условия, при которых это действие становится осознанным выбором специалиста. В рамках данной статьи мы проанализируем ситуацию, выясним основные причины такого подхода и разберем методологию работы с «чистыми» конфигурациями.
Одной из самых очевидных причин является физический размер файла .cf. Рассмотрим техническую сторону: когда база находится на поддержке, файл конфигурации фактически содержит в себе две конфигурации — основную (редактируемую) и конфигурацию поставщика (эталонную). Это приводит к тому, что объем файла увеличивается ровно в два раза.
Проанализируем пример: современная конфигурация «1С:Бухгалтерия предприятия» или «1С:Зарплата и управление персоналом» в формате .cf может весить около 450–500 МБ. Если она находится на поддержке, размер файла достигает почти 1 ГБ. В условиях мегаполисов с гигабитным интернетом это не кажется проблемой, но разберем ситуацию в регионах или при работе через мобильные каналы связи (2G/3G). Пересылка лишних 500 МБ через медленный интернет может занять часы, что критично для оперативной поддержки клиентов. Полное снятие с поддержки позволяет передавать только необходимые изменения, экономя время и дорогостоящий трафик.
Выясним, как наличие поддержки влияет на распределенные системы. При обновлении конфигурации в РИБ платформа должна передать изменения во все периферийные узлы. Если конфигурация снята с поддержки, в пакет обмена попадает только основная конфигурация. Если же поддержка сохранена, объем данных в сообщениях обмена существенно возрастает, так как системе приходится синхронизировать и данные поставщика.
Рассмотрим преимущества отсутствия поддержки в многоуровневых РИБ:
Многие опытные программисты используют схему разработки, при которой рабочая база полностью снята с поддержки, а все обновления готовятся на отдельной «инструментальной» базе. Проанализируем этот алгоритм по шагам:
.cf файл (уже без поддержки для минимизации веса).Для автоматизации этого процесса профессионалы используют XML-файл настроек объединения конфигураций. Это позволяет сохранять настройки сравнения (какие объекты брать из поставщика, а какие оставлять доработанными) и применять их при каждом обновлении, не тратя время на ручную расстановку «галочек».
Пример структуры работы с настройками (мета-код процесса):
// При сравнении конфигураций в интерактивном режиме
// используется возможность "Сохранить настройки" в XML.
// В дальнейшем этот файл подключается для автоматизации выбора объектов.
// Это исключает человеческий фактор при обновлении "отвязанных" баз.
Иногда полное снятие с поддержки является единственным способом «вылечить» базу. Разберем ситуацию: при некорректных обновлениях или сбоях СУБД внутренняя таблица Config может содержать фантомные записи о конфигурации поставщика, которые блокируют дальнейшие обновления или вызывают ошибки формата потока. В таких случаях программисты выполняют полное снятие с поддержки, чтобы очистить метаданные от накопившегося программного мусора, а затем (при необходимости) привязывают чистый .cf поставщика заново.
При переходе на современные инструменты разработки, такие как 1C:Enterprise Development Tools (EDT) и Git, хранение конфигурации поставщика внутри базы становится избыточным. Версионирование, отслеживание изменений и слияние веток происходят на уровне исходных кодов. В этой парадигме .cf файл является лишь артефактом сборки. Отсутствие поддержки в нем упрощает работу с репозиторием и ускоряет процессы CI/CD (автоматической сборки и тестирования), так как системе не нужно обрабатывать лишний гигабайт дублирующихся данных поставщика при каждой итерации.
Проанализируем влияние поддержки на производительность самого инструмента разработчика. При выполнении глобального поиска, поиске ссылок или открытии сложных объектов метаданных платформа вынуждена проверять состояние «замочков» и сопоставлять объекты с конфигурацией поставщика. В огромных конфигурациях (класса ERP) полное снятие с поддержки может дать субъективный прирост скорости отклика интерфейса Конфигуратора, особенно на серверах с ограниченными ресурсами оперативной памяти.
Важно помнить: Полное снятие с поддержки — это инструмент, требующий высокой квалификации. Главный риск заключается в том, что при следующем обновлении программист может забыть, какие именно изменения были внесены. Чтобы минимизировать риски, мы рекомендуем:
Таким образом, мы выяснили, что снятие с поддержки — это не всегда «рукожопство». Это может быть оправданным техническим решением для оптимизации инфраструктуры, ускорения разработки и обхода ограничений платформы в специфических условиях эксплуатации.