← На главную

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

Подготовка и техника безопасности перед обновлением

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

1. Создание резервной копии. Сделаем физическую копию базы (бэкап средствами СУБД для клиент-серверного варианта или выгрузку файла .dt, если база файловая).
2. Завершение сеансов. Завершим работу всех активных пользователей в системе.
3. Блокировка фоновых заданий. Обязательно заблокируем выполнение фоновых и регламентных заданий (через консоль кластера серверов 1С). Если этого не сделать, фоновое задание может заблокировать таблицы в момент реструктуризации базы данных, что приведет к фатальной ошибке.

Способ 1: Использование файла .cf (Оптимальный алгоритм)

Самый распространенный метод для разовых баз — подготовка полного файла конфигурации .cf в тестовой среде и его загрузка в рабочую базу. Однако здесь кроется главная опасность: если просто загрузить файл, конфигурация базы данных обновится, но версия «Конфигурации поставщика» останется старой. Это приведет к проблемам при следующих обновлениях. Разберем правильный алгоритм переноса:

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

Способ 2: Создание собственного файла обновления (.cfu)

Если у нас есть несколько одинаково доработанных баз (например, узлы РИБ или филиалы), переносить .cf в каждую будет долго и неэффективно. Рассмотрим метод создания собственного файла обновления.

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

Способ 3: Использование Хранилища конфигурации

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

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

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

Современные подходы: Расширения и 1C:EDT

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

Для крупных команд всё чаще применяется 1C:Enterprise Development Tools (EDT) в связке с системами контроля версий (например, Git). Это позволяет использовать ветвления кода, автоматизированное тестирование и CI/CD (непрерывную интеграцию). Изменения доставляются в продуктивную среду автоматически, исключая ручные манипуляции с выгрузкой и загрузкой файлов.

Важность запуска в режиме «Предприятие»

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

После завершения работы в Конфигураторе мы обязаны запустить рабочую базу в режиме 1С:Предприятие от имени пользователя с полными правами. В некоторых случаях для форсированного запуска требуется использовать параметр командной строки:

/С ЗапуститьОбновлениеИнформационнойБазы

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