Как правильно обновить конфигурацию 1С, подключенную к хранилищу, и актуализировать версию поставщика

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

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

Почему «просто накатить CF» — это плохая практика?

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

Метод 1: Полное обновление через захват корня конфигурации (Рекомендуемый)

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

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

Метод 2: Обновление рабочих баз из хранилища

Когда в хранилище уже находится «чистая» и обновленная версия, процесс актуализации 10 (или любого другого количества) рабочих баз значительно упрощается. Разберем, как сделать это быстро:

Проанализируем ситуацию: нам больше не нужно запускать процедуру сравнения/объединения в каждой рабочей базе. Нам достаточно получить последние изменения из хранилища. Алгоритм действий следующий:

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

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

"C:\Program Files\1cv8\common\1cestart.exe" DESIGNER /S "Server\BaseName" /N "Admin" /P "Pass" /ConfigurationRepositoryF "tcp://RepoServer/RepoName" /ConfigurationRepositoryN "RepoUser" /ConfigurationRepositoryP "RepoPass" /ConfigurationRepositoryUpdateCfg /UpdateDBCfg

Что делать, если хранилище «испорчено» или возник рассинхрон?

Бывают случаи (как в сообщении 12), когда структура хранилища настолько запутана предыдущими некорректными действиями, что проще создать его заново. Посмотрим, как правильно пересоздать хранилище, не потеряв текущие наработки.

Разберем процесс «лечения» через пересоздание:

1. Полностью обновите одну эталонную базу (например, головную) до нужного релиза, исправив все ошибки в коде и актуализировав конфигурацию поставщика (см. Метод 1).
2. Отключите эту базу от старого хранилища: Конфигурация — Хранилище конфигурации — Отключиться от хранилища.
3. Создайте новое пустое хранилище в новом каталоге: Конфигурация — Хранилище конфигурации — Создать хранилище.
4. Подключите все остальные рабочие базы к этому новому хранилищу. При подключении 1С предложит сравнить конфигурацию базы с хранилищем — соглашаемся и приводим их к единому знаменателю.

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

Оптимизация работы разработчиков

Выясним причину, по которой программисты боятся обновлений в хранилище. Главная проблема — Full Lock (полная блокировка). Когда вы захватываете корень рекурсивно, никто другой не может править код. Чтобы минимизировать это время, рекомендуем:

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

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