← На главную

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

Почему нельзя просто «накатить» cf-файл?

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

1. Нарушение версионности: История изменений в хранилище перестает соответствовать реальности в базе.
2. Рассинхрон метаданных: Конфигурация поставщика в хранилище и текущая версия в базе начнут конфликтовать, что в будущем приведет к невозможности корректного обновления.
3. Потерю данных: При принудительной загрузке структуры метаданных из cf-файла могут быть удалены объекты или реквизиты, что приведет к немедленному удалению данных из таблиц базы данных при обновлении конфигурации БД.

Правильный подход: обновление через Хранилище

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

Шаг 1: Обновление через тестовую среду. Подключите тестовую базу к Хранилищу. В этой базе выполните обновление конфигурации поставщика до требуемого релиза. Используйте стандартный механизм сравнения и объединения, чтобы актуализировать структуру.

Шаг 2: Помещение изменений. После того как тестовая база приведена в актуальное состояние и протестирована, все захваченные объекты необходимо поместить обратно в Хранилище. Теперь Хранилище содержит обновленную структуру, которая соответствует вашим cf-файлам.

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

Что делать, если нужно последовательно накатить множество промежуточных релизов?

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

1. Выполняем обновление в тестовой базе до первого промежуточного этапа.
2. Проводим тестирование работоспособности и выполнение всех необходимых процедур обновления данных.
3. Помещаем эти изменения в Хранилище.
4. Обновляем рабочую базу из Хранилища.
5. Повторяем цикл для следующего релиза.

Такой подход обеспечивает контролируемость каждого этапа перехода и сохранение целостности базы данных.

Альтернативный путь: работа без постоянного подключения

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

Как реализовать этот метод:

1. Подготовьте финальный cf-файл в базе, подключенной к хранилищу.
2. В рабочей (отключенной) базе выберите пункт Сравнить, объединить с конфигурацией из файла.
3. В процессе объединения аккуратно разрешите все конфликты метаданных.
4. Примените изменения и обновите конфигурацию базы данных.

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

Краткие рекомендации

Подводя итог, можно сделать следующие выводы:

• Никогда не отключайте рабочую базу от Хранилища для «быстрой» загрузки cf-файла, если вы не готовы вручную решать проблемы с метаданными и потенциальной потерей данных.
• Используйте тестовую копию как плацдарм для всех операций.
• Всегда делайте Бэкап базы данных перед любыми манипуляциями с конфигурацией, даже если вы уверены в своих действиях.
• Стремитесь к тому, чтобы Хранилище всегда отражало актуальное состояние разработки, а рабочая база лишь подтягивала эти изменения.

Помните, что архитектура 1С спроектирована таким образом, чтобы защитить данные от необдуманных действий. Работа «через Хранилище» — это стандарт индустрии, который обеспечивает стабильность крупных проектов и позволяет команде эффективно управлять изменениями.