Часто при поддержке доработанных (нетиповых) конфигураций 1С возникает потребность подготовить обновление заранее, чтобы в день "Х" быстро накатить изменения на рабочую базу и минимизировать время простоя пользователей. Разберем типичную ситуацию: разработчик создает пустую конфигурацию с новым релизом, переносит туда все нетиповые доработки, выгружает готовый файл .cf и пытается применить его к рабочей базе. Но в процессе он сталкивается с рядом критических ошибок и ограничений. Рассмотрим подробнее, почему так происходит и как выглядит профессиональная методология обновления.
Проанализируем три самых популярных неверных способа накатить файл конфигурации, подготовленный в "пустой базе", и выясним причину возникновения ошибок в каждом из них.
Если мы воспользуемся пунктом меню Загрузить конфигурацию из файла, то в режиме Предприятия процесс обновления данных не запустится, а структура базы данных будет непоправимо нарушена. При использовании этой кнопки происходит полная, безусловная замена текущей конфигурации на ту, что находится в файле. Главная опасность кроется во внутренних уникальных идентификаторах (UUID) объектов. Если мы создавали объекты (справочники, документы, реквизиты) или переносили доработки в новую пустую базу вручную, их скрытые идентификаторы будут отличаться от тех, что находятся в рабочей базе. При загрузке такого файла платформа 1С решит, что старые объекты нужно удалить (вместе со всеми пользовательскими данными!), а новые — создать "с нуля". Это приведет к катастрофической потере данных.
При выборе подготовленного файла .cf система выдает сообщение о том, что новая конфигурация не найдена. Дело в том, что в платформе 1С одновременно существует несколько сущностей конфигурации. Главные из них — это основная конфигурация (с которой мы работаем) и конфигурация поставщика (исходная структура от фирмы 1С, хранящаяся внутри базы). Штатный механизм обновления через поддержку опирается именно на конфигурацию поставщика. Если наш файл .cf был сделан в чистой пустой базе, где структура поддержки была нарушена или версии поставщика не совпадают, конфигуратор рабочей базы просто не распознает этот файл как легитимное обновление. Платформа не видит связи между конфигурацией поставщика в файле и в рабочей базе.
Если мы попытаемся использовать этот метод, то заметим, что часть объектов, в частности общие модули, не обновляются и не берутся из файла. Механизм сравнения и объединения по умолчанию игнорирует изменения для тех объектов, которые в рабочей базе находятся на «полной поддержке» (помечены желтым кубиком с замком). Чтобы объекты взялись из нашего файла, в рабочей базе необходимо предварительно включить возможность изменения (через Настройка поддержки). Однако использовать данный метод для обновления типового функционала категорически не рекомендуется: при этом не обновится версия конфигурации поставщика, и в будущем штатные обновления перестанут работать корректно.
Разработка отдельного .cf файла в «пустой базе» является в корне неверным подходом. Смысл делать правки в новой пустой конфигурации полностью отсутствует, так как можно потратить это же время на копии своей базы и сразу проверить результат на реальных данных.
Разберем по шагам правильный, безопасный алгоритм обновления, который применяют опытные специалисты:
Конфигурация — Поддержка — Обновить конфигурацию. В качестве источника используем типовой файл обновления .cfu или полный файл .cf от поставщика (например, от самой фирмы 1С)..cf. Теперь он содержит правильные идентификаторы доработок и обновленную конфигурацию поставщика.Конфигурация — Поддержка — Обновить конфигурацию, где выбираем выгруженный на 6 шаге файл .cf.При таком подходе платформа корректно и автоматически обновит конфигурацию поставщика, а также применит все наши выверенные доработки без необходимости повторного ручного разбора конфликтов в окне объединения.
Рассмотрим еще один критически важный аспект. Часто при длительном отсутствии обновлений возникает соблазн "перепрыгнуть" сразу через несколько релизов, накатив итоговый .cf файл последнего релиза. Пропускать релизы, не рекомендованные к пропуску самой фирмой 1С, категорически запрещено.
Посмотрим на пример того, как разработчики конфигураций модифицируют структуру данных. Часто удаление устаревших объектов происходит в два этапа:
Удалить_ИмяРеквизита, создают новый реквизит и прописывают в коде (в обработчиках обновления) алгоритм переноса данных из старого реквизита в новый. Этот код отрабатывает исключительно при первом запуске программы в режиме 1С:Предприятия.Если мы обновимся сразу с нулевого релиза до релиза №3, пропустив промежуточные, то алгоритм переноса данных просто не успеет отработать. Реквизит будет физически удален платформой на этапе реструктуризации базы данных в Конфигураторе, и все накопленные в нем данные будут безвозвратно утеряны. Поэтому, если нужно обновить сильно отставшую базу, необходимо готовить промежуточные файлы .cf на каждый важный шаг (релиз), запускать Предприятие после каждого обновления на копии, и только затем переходить к следующему шагу.