← На главную

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

Понимание механизма конфигурации поставщика в среде хранилища

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

Шаг 1. Подготовка и захват объектов

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

1. Захват корня конфигурации. Это обязательное условие. В корне конфигурации (самый верхний элемент в дереве метаданных) хранится информация о версии конфигурации поставщика и текущих настройках поддержки. Если вы обновите базу без захвата корня, изменения применятся локально, но вы не сможете «поместить» их в хранилище, и другие разработчики их не увидят.
2. Проверка захваченных объектов другими пользователями. Если обновление предполагает изменение кода или свойств объектов, которые в данный момент захвачены вашими коллегами, процедура помещения в хранилище после обновления завершится ошибкой. Проанализируем список захваченных объектов через Администрирование — Хранилище конфигурации — Управление хранилищем. Попросим коллег освободить объекты или, в крайнем случае, выполним принудительную отмену захвата, если это позволяют внутренние регламенты.
3. Рекурсивный захват (опционально). Если планируется масштабное обновление с изменением множества объектов, можно выполнить рекурсивный захват всей конфигурации, начиная с корня. Однако, как показывает практика, для опытного разработчика достаточно захватить только те объекты, которые реально изменятся, и обязательно — корень.

Шаг 2. Процедура обновления через поддержку

Теперь разберем основной процесс обновления. Мы не будем использовать методы «Сравнить и объединить с конфигурацией из файла», так как это может привести к потере связи с поддержкой. Используем штатный механизм:

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

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

Шаг 3. Помещение изменений в хранилище

После завершения процесса обновления в локальной базе, нам необходимо передать эти данные коллегам. Выполним команду Конфигурация — Хранилище конфигурации — Поместить в хранилище. В окне помещения мы увидим обновленный корень конфигурации и все измененные объекты. Обязательно добавим комментарий к версии, например: «Обновление конфигурации поставщика до версии 3.0.XXX».

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

Риски и методы их минимизации

Проанализируем возможные проблемы, с которыми можно столкнуться:

1. Потеря идентификаторов (GUID). Никогда не используйте схему «Снять с поддержки — Поставить на поддержку» для обновления в хранилище. Это гарантированно приведет к дублированию объектов или невозможности сопоставить изменения в будущем. Используйте только штатный механизм обновления.
2. Размер хранилища. Каждое обновление конфигурации поставщика записывает в историю хранилища фактически полный объем файла .cf. Это приводит к быстрому росту файла 1cv8ddb.1cd. Разберем, как с этим бороться: после успешного обновления рекомендуется выполнить сокращение хранилища через меню Администрирование — Хранилище конфигурации — Сократить. Это удалит старые тяжелые версии и повысит скорость работы системы.
3. Зависания на больших базах. Для крупных конфигураций, таких как ERP, визуальный интерфейс сравнения может работать крайне медленно. В таких случаях рассмотрим вариант подготовки файла обновления в отдельной копии базы, а затем в основной базе (с захваченным корнем) выполним сравнение и объединение с этим подготовленным файлом. Это позволит сократить время блокировки корня конфигурации.

Резюме

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