В процессе сопровождения и разработки систем 1С часто возникает вопрос: допустимо ли подключать продуктивную (рабочую) информационную базу непосредственно к хранилищу конфигурации? Рассмотрим технические риски такого подхода, проанализируем возможные исключения и разберем эталонный регламент переноса изменений с разделением контуров разработки и тестирования.
Чем опасно прямое подключение рабочей базы к хранилищу
На первый взгляд подключение рабочей базы к хранилищу кажется удобным: программист помещает код из тестовой базы в хранилище, после чего сразу обновляет рабочую базу в пару кликов. Однако такой подход сопряжен с серьезными рисками для сохранности данных и стабильности работы системы.
Проанализируем основные проблемы, возникающие при таком решении:
Помещение сырого или неоттестированного кода. Если в хранилище работают несколько разработчиков, один из них может поместить незавершенные правки. При обновлении рабочей базы из хранилища в продакшен попадут чужие неготовности или ошибки, что может полностью заблокировать работу пользователей.
Конфликты связей и зависимостей метаданных. При частичной синхронизации объектов из хранилища часто возникают ситуативные ошибки. Например, если в хранилище была помещена подписка на событие, но не был получен модуль ее обработчика, или создан новый регистр сведений без документа-регистратора. Платформа потребует получить рекурсивно все связанные объекты, что вынудит обновить незапланированные участки системы.
Технические сбои и повреждение структур СУБД. В момент обмена данными с хранилищем при некорректном разрыве сети или динамическом обновлении могут быть повреждены системные таблицы метаданных Config и ConfigSave. Это приводит к рассинхронизации базы и хранилища, выдаче ошибок вида «Информационная база не связана с хранилищем конфигурации» или зависанию Конфигуратора.
Блокировка пользователей и проблемы фоновых заданий. Выполнение операции получения конфигурации из хранилища на крупной базе (сотни гигабайт) накладывает эксклюзивные блокировки на метаданные, что приводит к завершению пользовательских сеансов и сбоям регламентных процедур.
Когда прямое подключение допустимо
Разберем случаи, когда подключение хранилища к продуктиву допустимо как компромиссное решение:
В проекте работает единственный разработчик, полностью контролирующий состав изменений и время их помещения.
Информационная база является полностью самописной или снята с поддержки, а бизнес-процессы допускают оперативные исправления (hotfix) в рабочее время.
Применяется отдельное хранилище релизов (Main/Prod), в которое помещаются только полностью оттестированные сборки из хранилища разработки (Dev).
Рекомендуемый регламент переноса изменений (Dev — Test — Prod)
Для исключения рисков сбоя рабочей базы проанализируем классическую безопасную схему развертывания updates (CI/CD или ручной регламент поставки):
Контур разработки (Dev): Программисты выполняют задачи в своих локальных базах, подключенных к хранилищу разработки. Все правки коммитятся и фиксируются в истории хранилища.
Контур тестирования (Test): Из хранилища создается тестовая конфигурация. На тестовой базе выполняются автоматические и ручные тесты.
Формирование файла поставки: После успешного тестирования из главной ветки разработки выгружается файл конфигурации .cf или файл обновления .cfu.
Обновление рабочей базы (Prod): В технологическое окно (после создания резервной копии базы) конфигурация рабочей базы обновляется путем сравнения и объединения или полной загрузки файла .cf. Рабочая база остается автономной и не имеет прямой связи с файлами хранилища.
Использование расширений конфигурации для безопасных доработок
Если требуется подключить сторонний функционал (например, модуль обмена от подрядчика или франчайзи), лучшей практикой является использование расширений конфигурации (файлы .cfe).
Посмотрим на преимущества такого подхода:
Основная конфигурация рабочей базы остается на замке и не снимается с поддержки.
Не требуется создавать хранилище конфигурации или изменять структуру основной базы.
При возникновении ошибки расширение можно оперативно отключить в режиме 1С:Предприятие без потери основных данных.
Автоматизация обновления рабочей базы через командную строку
Для исключения человеческого фактора при обновлении продуктивного контура разберем пример автоматизации пакетного обновления информационной базы из подготовленного файла поставки .cf с помощью командной строки платформы 1С:
Если в организации все же принято решение использовать сервер хранилища для автоматической сборки, целесообразно использовать службу сервера хранилища crserver.exe и запускать обновление по расписанию специальным ключом:
Подведем итог: Прямое подключение рабочей базы к хранилищу разработки не рекомендуется стандартизованной методологией 1С. Для обеспечения отказоустойчивости и сохранности данных следует разделять среды разработки и продакшена, выполняя обновления рабочей базы исключительно через проверенные файлы поставки (.cf / .cfu) или изолированные расширения (.cfe).