← На главную

Разработчики и администраторы крупных систем 1С часто сталкиваются с дилеммой: с одной стороны, групповая разработка требует обязательного использования Хранилища конфигурации, с другой — автоматизированные сервисы обновления (например, популярный сервис от «1С-ИжТиСи») или сторонние подрядчики предоставляют готовый файл обновления в формате .cf, предполагающий использование операции «Загрузить конфигурацию из файла».

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

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

Почему сервисы обновления требуют именно «Загрузить конфигурацию из файла»?

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

Дело в механизме сопоставления объектов метаданных платформой 1С:

• При полной загрузке конфигурации (Загрузить конфигурацию из файла) сопоставление абсолютно всех объектов происходит по их внутренним уникальным идентификаторам — GUID. Если в новом релизе разработчик поставщика переименовал какой-то реквизит или справочник, платформа безошибочно поймет это переименование. Данные при обновлении базы данных (F7) сохранятся, а физическая таблица в СУБД просто сменит имя колонки или таблицы.
• При сравнении и объединении (Сравнить, объединить с конфигурацией из файла) платформа сначала пытается сопоставить объекты по их именам (синонимам и идентификаторам), а уже потом анализирует внутренние GUID. Если объект был переименован, механизм сравнения может посчитать, что старый объект удален, а новый — добавлен. Если вы согласитесь с таким объединением, то при обновлении базы данных физическая таблица или колонка со всеми накопленными данными пользователей будет удалена, а вместо нее создастся новая, пустая. Это приводит к катастрофической потере данных в рабочей базе.

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

---

Решение 1. Классическая двухбазовая схема (Разработка / Прод)

Это самый надежный, проверенный временем метод, который используют ведущие специалисты по внедрению систем класса ERP и Комплексная автоматизация. Суть метода заключается в разделении контуров применения обновлений.

Нам понадобятся две отдельные информационные базы:

1. База разработки (Препрод / Копия) — база, которая НЕ подключена к хранилищу конфигурации. На ней мы проводим все технологические эксперименты и предварительную подготовку обновлений.
2. Рабочая база (Прод) — база, подключенная к основному хранилищу конфигурации, в которой ведется групповая разработка и работают пользователи.

Рассмотрим пошагово алгоритм переноса обновлений из файла .cf в рабочее хранилище:

Шаг 1. Подготовка файла в базе разработки

В нашей базе разработки (которая отключена от хранилища) мы без всяких препятствий выполняем операцию «Конфигурация» — «Загрузить конфигурацию из файла» и выбираем полученный от сервиса обновления или поставщика файл .cf. После успешного завершения загрузки выполняем обновление конфигурации базы данных (клавиша F7). Из этой базы мы выгружаем результирующий файл конфигурации (назовем его result.cf), который содержит и обновленную конфигурацию поставщика, и все наши доработки.

Шаг 2. Обновление конфигурации поставщика в рабочей базе

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

Для этого выполняем следующие действия:

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

Шаг 3. Захват объектов и перенос изменений

Теперь необходимо перенести сами изменения кода и структуры метаданных из подготовленного нами на Шаге 1 файла result.cf.

1. В рабочей базе выполняем рекурсивный захват всех объектов в хранилище. Для этого нажимаем правой кнопкой мыши на корневой элемент дерева метаданных (имя конфигурации) и выбираем команду «Захватить в хранилище...». В открывшемся окне обязательно устанавливаем флаг «Захватывать рекурсивно».
2. После того как вся конфигурация успешно захвачена вами (и никто другой из разработчиков не может вносить изменения), переходим в меню «Конфигурация» — «Сравнить, объединить с конфигурацией из файла...».
3. Выбираем наш подготовленный файл result.cf.
4. В окне сравнения и объединения убеждаемся, что все объекты сопоставлены верно. Так как мы предварительно обновили конфигурацию поставщика на Шаге 2, сопоставление пройдет без конфликтов и дублирования объектов.
5. Выполняем объединение конфигураций.
6. Нажимаем клавишу F7, чтобы обновить конфигурацию базы данных. Проводим быстрое тестирование системы.
7. Помещаем все объекты обратно в хранилище (также рекурсивно, с фиксацией истории изменений и подробным комментарием к релизу).

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

---

Решение 2. Имитация «Загрузки» через правила объединения

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

Разберем этот альтернативный вариант по шагам:

1. Открываем рабочую базу в режиме Конфигуратора.
2. Выполняем полный рекурсивный захват всех объектов в хранилище конфигурации.
3. Выбираем пункт меню «Конфигурация» — «Сравнить, объединить с конфигурацией из файла...» и указываем полученный от «1С-ИжТиСи» или разработчиков файл .cf.
4. После завершения анализа сравнения перед нами откроется дерево объектов. По умолчанию платформа предлагает мягкое объединение. Наша задача — изменить это поведение.
5. Снимаем все флажки объединения (можно кликнуть по корню и снять общую галку).
6. Нажимаем правой кнопкой мыши по самому верхнему элементу (корню конфигурации) и в контекстном меню выбираем пункт «Установить режим для всех объектов...» (или «Установить пометки по...»).
7. В открывшемся окне настройки правил устанавливаем режим «Взять из файла» (или полностью заменить свойствами файла). Нам необходимо добиться того, чтобы напротив каждого измененного или нового объекта стояла отметка о полной замене его свойств данными из файла .cf.
8. Нажимаем кнопку «Выполнить». Платформа перезапишет свойства, модули и формы захваченных объектов метаданных в соответствии с содержимым файла.
9. Выполняем обновление базы данных (F7) и возвращаем все объекты в хранилище.

Внимание: этот способ требует высокой концентрации внимания. Если вы случайно пропустите объект или не настроите правило замещения «Взять из файла» для какого-то сложного доработанного механизма, вы рискуете получить рассогласование метаданных.

---

Решение 3. Полное удаление конфигурации поставщика из рабочей базы

В некоторых ИТ-отделах практикуется радикальный, но действенный метод ускорения работы с хранилищем на сильно кастомизированных конфигурациях. Если типовой функционал переписан более чем на 50%, регулярное обновление конфигурации поставщика превращается в пустую трату времени.

В таком случае принимается решение полностью снять рабочую базу с поддержки поставщика:

1. В рабочей базе захватываем корень конфигурации.
2. Переходим в «Конфигурация» — «Поддержка» — «Настройка поддержки».
3. Нажимаем кнопку «Снять с поддержки».

После этой процедуры база становится полностью «самописной» для платформы 1С. Конфигурация поставщика больше не хранится в базе данных, что существенно уменьшает размер файла .1cd (или таблиц в MS SQL / PostgreSQL) и ускоряет работу самого хранилища.

При этом весь процесс обновления переносится в «препрод» (копию) базы разработки. Именно там хранится конфигурация поставщика, там накатываются обновления через полную загрузку, а в рабочую базу (прод) изменения переносятся исключительно через сравнение-объединение (как описано в Решении 1). Рабочая база всегда остается чистой от балласта конфигурации поддержки.

---

Перспективное решение: Переход на EDT и Git

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

Использование среды разработки 1C:Enterprise Development Tools (EDT) в связке с системой контроля версий Git полностью снимает описанную проблему:

• В Git нет понятия «монопольного захвата объектов». Несколько разработчиков могут одновременно редактировать одни и те же модули или формы.
• Файл .cf, полученный от сервиса автоматического обновления, можно просто загрузить в локальную учебную базу, импортировать в проект EDT, и Git автоматически зафиксирует все изменения в виде обычного коммита кода.
• Слияние обновлений от поставщика и доработок вашей команды происходит на уровне текстовых файлов (в формате XML), что делает процесс прозрачным и исключает любые повреждения структуры базы данных.

Переход на EDT требует переобучения команды, но в долгосрочной перспективе это избавляет от рутинных ручных манипуляций в конфигураторе.

---

Резюме и рекомендации

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

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