Рано или поздно любой разработчик или администратор систем 1С сталкивается с задачей переноса сложных, нетиповых изменений из тестовой среды на рабочую (продакшн) базу данных. Ситуация, когда на тестовой базе все успешно обновлено, протестировано и работает без сбоев — это отличный промежуточный результат. Однако этап «накатывания» этих изменений на «живую» базу таит в себе множество скрытых угроз: от потери уникальных доработок других программистов до полной остановки работы предприятия из-за повреждения структуры базы данных.
В этой статье мы подробно разберем, как правильно перенести нетиповое обновление на рабочую базу, проанализируем доступные инструменты, сравним методы загрузки и объединения конфигураций, а также составим безопасный чек-лист, который убережет вас от фатальных ошибок.
Это самый первый и главный вопрос, который встает перед специалистом. Давайте детально разберем обе технологии, взвесим их преимущества и риски.
Вариант А: Загрузка конфигурации из файла (используя файл .cf)
Этот метод заключается в полной замене конфигурации рабочей базы подготовленным файлом конфигурации из тестовой базы. Для этого в Конфигураторе рабочей базы используется команда «Конфигурация» — «Загрузить конфигурацию из файла...».
Рассмотрим, почему это наиболее предпочтительный, чистый и быстрый способ:
Внимание! Главная опасность метода: Если в рабочей базе параллельно велась какая-то разработка (например, другой специалист оперативно исправил критический баг прямо в рабочей базе) или если за время тестирования конфигурация рабочей базы была изменена иным образом, то операция «Загрузить конфигурацию» безвозвратно затрет эти изменения.
Выясним, как застраховать себя от этой проблемы. Перед выполнением загрузки обязательно запустите функцию сравнения конфигураций. Для этого в рабочей базе выполните команду «Конфигурация» — «Сравнить конфигурации...». Сравните основную конфигурацию рабочей базы с вашим файлом .cf. Вы должны увидеть исключительно те изменения, которые внесли лично вы в процессе разработки обновления. Если обнаружились посторонние изменения — использовать прямую загрузку нельзя!
Вариант Б: Сравнение и объединение конфигураций
Этот метод применяется, когда в рабочей базе произошли изменения, которых не было на тесте, или если у вас нет полной уверенности в идентичности исходных конфигураций до начала процесса обновления. Для этого используется команда «Конфигурация» — «Сравнить, объединить с конфигурацией из файла...».
Проанализируем особенности этого подхода:
.cf, вы рискуете нарушить связь с конфигурацией поставщика. В результате база данных останется на старой поддержке, и при последующих обновлениях система будет некорректно определять текущую версию релиза.Если вам все же приходится использовать сравнение и объединение для нетиповой конфигурации, делайте это правильно. Обновление следует запускать через механизм поддержки: «Конфигурация» — «Поддержка» — «Обновить конфигурацию» (выбрав ваш файл обновления .cf или .cfu), либо через детальную настройку правил объединения в окне «Настройка поддержки» с последующим сравнением и объединением основных метаданных.
Разберем по шагам технологическую цепочку, которая минимизирует риски при переносе изменений на рабочую базу.
Шаг 1. Подготовка и создание надежного бэкапа
Никогда не приступайте к обновлению без резервной копии. Причем для крупных баз данных недостаточно просто выгрузить файл .dt. Файл .dt является логическим бэкапом, и в случае сбоя СУБД или повреждения структуры таблиц при реструктуризации он может просто не загрузиться обратно.
1Cv8.1CD в надежное место.Шаг 2. Анализ изменений перед загрузкой
Откройте рабочую конфигурацию. Выполните сравнение основной конфигурации с подготовленным файлом .cf. Убедитесь, что в списке различий присутствуют только ваши запланированные изменения. Если все чисто — переходите к следующему шагу.
Шаг 3. Загрузка конфигурации
Выполните команду «Конфигурация» — «Загрузить конфигурацию из файла...» и выберите ваш протестированный файл .cf. После завершения загрузки система предложит обновить конфигурацию базы данных. Нажмите «Да» (или клавишу F7). Внимательно изучите список изменений в структуре метаданных. Если система предупреждает об удалении объектов или реквизитов, убедитесь, что это запланированное действие и вы не теряете важные пользовательские данные.
Шаг 4. Применение изменений базы данных
Примените изменения конфигурации. На этом этапе происходит реструктуризация таблиц базы данных на уровне СУБД.
Рассмотрим подробнее детали, пренебрежение которыми чаще всего приводит к сбоям в работе продакшн-систем.
Перенос метаданных и кода в Конфигураторе — это лишь первая часть процесса. Почти все современные конфигурации 1С (ERP, КА, УТ, БП, ЗУП) построены на базе Библиотеки Стандартных Подсистем (БСП). В них заложен механизм отложенного обновления данных.
Когда вы обновили конфигурацию в Конфигураторе, физические таблицы в СУБД изменили свою структуру, но данные в них еще не приведены к новому формату. Для этого необходимо:
Динамическое обновление (так называемое обновление «на лету» без выгона пользователей) — это удобная, но крайне опасная функция. Если ваше обновление затрагивает структуру данных (добавлены новые реквизиты, изменены типы данных, созданы новые справочники или документы), динамическое обновление использовать строго запрещено!
Попытка обновить структуру БД динамически почти гарантированно приведет к ошибке «Нарушена целостность структуры конфигурации». В этом случае работа пользователей будет заблокирована, а базу придется восстанавливать из бэкапа или тратить часы на восстановление таблиц базы данных с помощью утилит тестирования и исправления.
Если ваша система постоянно дорабатывается, а обновления происходят регулярно, ручной перенос .cf-файлов рано или поздно приведет к ошибкам из-за человеческого фактора. Чтобы автоматизировать этот процесс и сделать его прозрачным, мы рекомендуем развернуть Хранилище конфигурации 1С.
Посмотрим, как выглядит правильная схема работы с использованием Хранилища:
Использование Хранилища позволяет версионировать код, видеть, кто и когда внес конкретные изменения, и минимизирует риск затереть чужие доработки при обновлении продакшн-среды.
Таким образом, соблюдение строгой технологической последовательности, обязательное предварительное сравнение метаданных рабочей базы и .cf-файла, отказ от динамических обновлений при изменении структуры таблиц и обязательный контроль выполнения обработчиков БСП гарантируют вам успешное и безопасное проведение нетипового обновления на рабочей базе данных.