Разработка и отладка программного кода непосредственно в рабочей информационной базе — одна из самых опасных практик в среде 1С. Даже при небольшом количестве активных пользователей постоянное открытие конфигуратора на «боевой» базе и сохранение промежуточных правок приводит к блокировкам, ошибкам СУБД и рискам повреждения данных. Разберем технические причины такого поведения системы и рассмотрим правильную организацию контура разработки.
Технические причины сбоев при работе в рабочем конфигураторе
Выясним, почему системный администратор и опытные специалисты категорически запрещают редактировать рабочую базу в процессе работы пользователей:
Блокировки системных таблиц метаданных. При внесении любых изменений конфигуратор захватывает и модифицирует служебные таблицы базы данных: CONFIG, CONFIGSAVE и PARAMS. В это же время клиентские сеансы пользователей непрерывно обращаются к этим таблицам для проверки прав, параметров сеанса и структуры объектов. В результате возникают взаимные блокировки (deadlocks) и превышения времени ожидания на стороне СУБД.
Ограничения 32-разрядной архитектуры СУБД. 32-битный процесс СУБД ограничен виртуальным адресным пространством объемом до 2–4 ГБ. При выполнении операций сериализации и десериализации метаданных конфигуратором параллельно с запросами пользователей СУБД испытывает дефицит непрерывной памяти под буферный пул, что вызывает критические ошибки ядра базы данных.
Эксклюзивные DDL-блокировки схемы. Любое изменение структуры данных (добавление реквизита в справочник или документ, изменение типа данных) требует физической реструктуризации таблиц. В СУБД накладываются монопольные блокировки изменения схемы (Schema Modification Lock в MS SQL Server или ACCESS EXCLUSIVE в PostgreSQL), что полностью парализует работу пользователей с затрагиваемыми таблицами.
Риск остановки транзакций в отладчике. Если разработчик случайно остановится точкой останова внутри открытой транзакции проведения документа, системные блокировки не будут сняты до завершения отладки. Это приводит к массовому зависанию сеансов всех пользователей.
Несогласованность кэша метаданных. Клиентские приложения 1С кэшируют структуру метаданных в оперативной памяти. Изменение схемы базы данных в режиме реального времени способно вызвать падение сеансов пользователей с ошибками несоответствия версий метаданных.
Организация безопасного контура разработки
Рассмотрим, как должен выглядеть базовый цикл внесения доработок в информационные системы 1С. Проанализируем разделение сред на практике:
Среда разработки (Dev). База данных, в которой программист создает новые объекты, правит модули и проводит первичное тестирование. База может быть файловой или развернутой на отдельном сервере СУБД для разработчиков.
Тестовая среда (Test / QA). Полная или обезличенная копия рабочей базы, обновляемая по регламенту. В ней проверяется корректность работы нового функционала на реальных объемах данных и тестируются обмены с внешними системами.
Рабочая среда (Production). Боевая база, доступ к конфигуратору которой строго регламентирован. В ней производятся только накатывание протестированных релизов и экстренное аварийное обслуживание.
Варианты переноса изменений в рабочую базу
Разберем три проверенных способа доставки доработок из среды разработки в продуктив.
1. Перенос через выгрузку файла конфигурации (.cf)
Подходит для небольших команд из 1–2 разработчиков. Рассмотрим последовательность шагов:
Все доработки выполняются и полностью отлаживаются в тестовой информационной базе.
В тестовом конфигураторе выполняется выгрузка конфигурации в файл через меню Конфигурация — Сохранить конфигурацию в файл (получаем файл .cf).
В нерабочее время (технологическое окно) создается резервная копия рабочей базы данных средствами СУБД или платформы.
В конфигураторе рабочей базы открывается меню Конфигурация — Сравнить, объединить с конфигурацией из файла, либо выполняется полная загрузка конфигурации через Конфигурация — Загрузить конфигурацию из файла (если рабочая база не снята с типовой поддержки или полностью совпадает с тестовой).
Выполняется обновление конфигурации базы данных клавишей F7.
2. Использование Хранилища конфигурации 1С
Для коллективной разработки применяется штатный инструмент — Хранилище конфигурации. Рассмотрим правильную схему работы с хранилищем:
Создается центральное хранилище конфигурации на выделенном сервере.
К хранилищу подключаются исключительно базы разработчиков (Dev) и база для сборки релизов (Build).
Разработчик захватывает конкретный объект в хранилище, вносит изменения, тестирует функционал локально и помещает объект обратно в хранилище с комментарием.
Для выпуска релиза конфигурация обновляется в специальной сборочной базе, подключенной к хранилищу, откуда выгружается итоговый файл поставки (.cf), который затем накатывается на рабочую базу.
Важное правило: Подключать рабочую базу напрямую к хранилищу конфигурации не рекомендуется, так как при частичном помещении недоработанного функционала одним из разработчиков существует риск случайного обновления рабочей базы нестабильной версией метаданных.
3. Использование расширений конфигурации (.cfe)
Если требуется добавить печатную форму, скорректировать логику проведения или добавить отчет без изменения основной конфигурации, целесообразно использовать механизм расширений:
Разработка функционала ведется в расширении .cfe.
Внедрение расширения в рабочую базу часто не требует монопольного захвата базы и реструктуризации таблиц, что сводит к минимуму время простоя пользователей.
Автоматизация обновления рабочей базы в пакетном режиме
Для минимизации человеческого фактора обновление конфигурации рабочей базы во внерабочее время можно выполнять скриптами через запуск 1С в пакетном режиме. Рассмотрим пример вызова конфигуратора через командную строку:
Установка блокировки сеансов и запуск обновления конфигурации базы данных:
Параметр /UC позволяет зайти в конфигуратор под кодом разрешения блокировки, когда для обычных пользователей вход в систему заблокирован.
Если обновление требует длительной реструктуризации больших таблиц на высоконагруженных системах, применяют механизм фоновой реструктуризации платформы. Подготовка изменений запускается заранее с параметром /UpdateDBCfg -BackgroundPrepare, а в технологическое окно выполняется быстрое финальное применение через -BackgroundFinish.
Регламент экстренного исправления ошибок (Hotfix)
Проанализируем ситуацию, когда в рабочей базе обнаружена критическая ошибка, требующая немедленного исправления, а в тестовой базе находится в разработке другой масштабный функционал:
Из рабочей базы выгружается актуальный файл конфигурации .cf.
На базе этого файла создается чистая временная база для хотфикса.
В ней вносится точечное исправление ошибки и проверяется результат.
Файл с исправлением объединяется с рабочей базой в согласованное короткое окно перезапуска пользователей.
После выпуска хотфикса внесенные правки обязательно переносятся в ветку основной разработки или помещаются в хранилище конфигурации.
Соблюдение регламента разделения сред гарантирует стабильность работы пользователей, исключает блокировки СУБД и защищает информационную базу от потери данных.