Разработка в среде 1С с использованием механизма хранилища конфигурации накладывает ряд жестких технологических ограничений. Одно из наиболее частых затруднений, с которым сталкиваются специалисты при сопровождении доработанных баз, — это блокировка стандартных инструментов обновления. В частности, при подключенном хранилище платформа делает неактивной команду «Загрузить конфигурацию из файла».
В этой статье мы подробно разберем причины такого поведения платформы, рассмотрим классическую двухпроходную схему обновления, изучим альтернативные экспресс-методы и выясним, как избежать фатальных ошибок, связанных с «пересортом» уникальных идентификаторов (UUID) метаданных.
Прежде чем переходить к алгоритмам обновления, проанализируем архитектурную логику платформы 1С:Предприятие. Хранилище конфигурации работает по принципу версионирования отдельных объектов (гранулярно). Каждый справочник, документ, реквизит или форма имеют свою историю версий, автора изменений и статус захвата.
Прямая загрузка файла конфигурации (.cf) представляет собой операцию полной и деструктивной замены всей структуры метаданных «одним махом». Если бы платформа разрешила выполнить эту команду при активном хранилище, связь между физическими объектами в базе данных разработки и их историей версий в хранилище была бы безвозвратно утеряна. Это привело бы к глубокому рассинхрону схемы данных и гарантированному краху репозитория при попытке любого разработчика обновить свою локальную копию.
Именно поэтому единственным штатным способом изменения структуры метаданных при подключенном хранилище является процедура сравнения и объединения конфигураций при предварительно захваченных объектах.
---
Рассмотрим наиболее надежный и безопасный сценарий, когда у вас уже есть готовый, протестированный файл обновления (.cf), собранный на локальной копии базы данных. Чтобы правильно перенести эти изменения в рабочую конфигурацию, подключенную к хранилищу, выполним следующие шаги по порядку.
При обновлении доработанных типовых решений критически важно обновить не только код, но и саму конфигурацию поставщика, которая находится на поддержке. Если просто сделать сравнение-объединение с обычным файлом .cf, конфигурация поставщика останется старой, что сделает невозможными все последующие автоматические обновления.
.cfu или полный дистрибутивный .cf нового релиза от вендора).Теперь, когда поддержка обновлена, мы можем безопасно перенести код и структуру из нашего подготовленного файла.
.cf, содержащий все новые доработки.F7 (или выбрав Конфигурация — Обновить конфигурацию базы данных).---
Существует менее известный, но чрезвычайно удобный альтернативный трюк. Он позволяет залить подготовленный файл .cf напрямую в хранилище, минуя рутинное сравнение с основной конфигурацией базы данных. Проанализируем этот алгоритм:
.cf с готовым обновлением.---
При переходе на принципиально новые архитектурные редакции тяжелых конфигураций (например, переход с «ERP Управление предприятием» версии 2.4 на 2.5) объем изменений настолько огромен, что стандартное сравнение-объединение в базе с хранилищем может выполняться десятки часов, зависать или аварийно завершаться по причине нехватки оперативной памяти. В таких экстраординарных случаях целесообразно использовать схему с пересозданием хранилища:
.cf.F7.Важный нюанс: главным минусом данного подхода является потеря детальной истории коммитов в старом хранилище. Тем не менее старый файл хранилища можно сохранить в архивном каталоге в режиме «только для чтения» для возможности ретроспективного анализа старого кода.
---
Разберем детально техническую тонкость, упомянутую опытными разработчиками в обсуждении на форуме. Это явление называется «пересортом» метаданных по внутренним UUID.
Платформа 1С идентифицирует любой объект конфигурации (например, справочник ДоговорыКонтрагентов или реквизит СуммаДокумента) не по его имени, а по уникальному 128-битному идентификатору (UUID). Если один и тот же новый справочник был создан вручную параллельно в рабочей базе и в базе разработки, они будут иметь абсолютно одинаковые имена, но разные внутренние UUID.
Если при обновлении вы запустите сравнение-объединение с включенным флагом «Устанавливать соответствие по именам объектов», платформа визуально объединит их. Однако при попытке последующих обновлений начнется хаос: система попытается удалить объект с одним UUID и создать заново с другим, что приведет к полной потере накопленных данных в пользовательской базе данных!
Выясним, как гарантировать отсутствие «пересорта» перед обновлением:
---
Для крупных проектов и системных администраторов, практикующих подход непрерывной интеграции (CI/CD), ручные манипуляции в конфигураторе малоэффективны. Платформа 1С поддерживает пакетный режим работы с хранилищем. Рассмотрим пример типового пакетного скрипта для автоматического получения обновлений из хранилища:
"C:\Program Files\1cv8\8.3.22.1709\bin\1cv8.exe" DESIGNER /F "C:\1C_Bases\WorkDB" /N "Admin" /P "Password" /ConfigurationRepositoryF "\\server\repository" /ConfigurationRepositoryN "DeployUser" /ConfigurationRepositoryP "DeployPassword" /ConfigurationRepositoryUpdateCfg /UpdateDBCfg
В данном примере используются следующие ключевые параметры запуска:
/ConfigurationRepositoryF — указывает сетевой путь к файлу хранилища конфигурации./ConfigurationRepositoryN и /ConfigurationRepositoryP — авторизационные данные служебного пользователя хранилища с правами на просмотр и захват./ConfigurationRepositoryUpdateCfg — команда, инициализирующая автоматическое стягивание всех последних изменений из хранилища в основную конфигурацию базы данных./UpdateDBCfg — финальное обновление конфигурации базы данных (аналог нажатия F7).Использование таких скриптов в связке с планировщиками задач или специализированным софтом (например, «Обновлятор-1С») позволяет полностью автоматизировать рутинный процесс обновления клиентских баз в ночное время, сводя к минимуму влияние человеческого фактора.