Вопрос о том, стоит ли подключать рабочую (промышленную) базу напрямую к хранилищу конфигурации, является камнем преткновения для многих команд разработки. С одной стороны, это кажется удобным: нажал кнопку «Получить из хранилища», обновил конфигурацию базы данных, и изменения уже у пользователей. С другой стороны, опытные администраторы и разработчики часто называют такой подход «самоубийством». В этой статье мы подробно проанализируем ситуацию, разберем технические и организационные риски, а также рассмотрим эталонную схему организации процесса обновления.
Разберем, что происходит «под капотом» системы, когда рабочая база связана с хранилищем. Основная проблема заключается в том, что хранилище — это инструмент коллективной разработки, а не средство доставки обновлений в промышленную среду.
1. Неустойчивость связи и повреждение конфигурации
Если в момент получения изменений из хранилища произойдет сетевой сбой или кратковременный разрыв соединения с сервером 1С, конфигурация базы данных может зависнуть в промежуточном состоянии. Рассмотрим последствия: таблицы метаданных (например, Config или ConfigCascading в SQL-базе) могут оказаться заблокированными. В худшем случае это потребует ручного вмешательства в структуру таблиц на уровне СУБД, что всегда сопряжено с риском полной потери работоспособности базы.
2. Проблемы с кэшированием и «демоническим» обновлением
Подключение к хранилищу провоцирует администраторов на частое использование динамического обновления. Проанализируем риски: при наличии связи с хранилищем система создает объемные локальные кэши на стороне сервера приложений. При нестабильности хранилища этот кэш повреждается, что приводит к непредсказуемым ошибкам: от «Объект изменен или удален» до аварийного завершения сеансов пользователей.
3. Раздувание служебных данных
Рабочая база начинает хранить в себе историю связей с объектами хранилища. Для крупной конфигурации это означает лишнюю нагрузку на дисковую подсистему и увеличение времени выполнения регламентных операций.
Даже если технически всё работает стабильно, возникают риски, связанные с процессом разработки. Выясним причину, по которой прямое подключение считается плохим тоном в DevOps-практиках 1С.
Случайный захват и помещение кода
При наличии доступа к хранилищу из рабочей базы существует риск того, что кто-то из разработчиков (или администратор под учетной записью с правами на хранилище) случайно поместит изменения из «прода» в хранилище или наоборот. Это нарушает целостность веток разработки.
Попадание «сырого» кода
Представим ситуацию: три разработчика одновременно ведут задачи. Один из них поместил в хранилище промежуточный вариант кода, чтобы не потерять его перед уходом на обед. В этот же момент администратор рабочей базы нажимает «Получить из хранилища», чтобы накатить изменения по другой задаче. В итоге недописанный, неработающий код попадает в промышленную базу. Рассмотрим пример ошибки, которая часто возникает в таких случаях:
// Разработчик добавил вызов новой функции, но саму функцию еще не поместил в хранилище
Процедура ПередЗаписью(Отказ)
ОбновитьДанныеМаркировки(); // Ошибка: Процедура не обнаружена!
КонецПроцедуры
Проблемы с правами доступа
Посмотрим на пример с добавлением новых метаданных. Разработчик создал новый регистр сведений РегистрУчетаАкцизов и назначил его регистратором существующий документ. Если он поместит эти изменения в хранилище, но забудет обновить роли (права доступа), то у обычных пользователей документ перестанет проводиться с ошибкой нарушения прав, хотя у администратора всё будет работать корректно.
Чтобы минимизировать риски, разберем по шагам классическую надежную схему, которую используют крупные внедренцы. Суть её заключается в том, что рабочая база никогда не подключается к «боевому» хранилищу разработчиков.
.cf файл (конфигурация). Здесь же проводится финальное тестирование..cfu.Такой подход гарантирует, что в рабочую базу попадет только тот код, который прошел полный цикл тестирования, и никакие промежуточные действия разработчиков не повлияют на стабильность системы.
Если вы всё же решили использовать хранилище в связке с рабочими базами (например, в небольших проектах), прислушайтесь к следующим рекомендациям:
Используйте сервер хранилища (tcp)
Никогда не подключайте рабочую базу к хранилищу через файловую шару (протокол file://). Это крайне медленно и ведет к повреждению базы при малейшем лаге сети. Используйте только серверный вариант (протокол tcp://).
Разделяйте учетные записи
Для подключения рабочей базы к хранилищу создайте отдельного служебного пользователя в хранилище (например, Admin_Production). У этого пользователя должны быть права только на просмотр и получение данных, но ни в коем случае не на захват объектов.
Регулярное обслуживание
Хранилище 1С имеет свойство накапливать ошибки. Проанализируем необходимость регламентных работ: раз в несколько месяцев рекомендуется выполнять оптимизацию хранилища и проверку его целостности средствами конфигуратора. Если хранилище начинает «глючить», лучше пересоздать его из актуального .cf файла рабочей базы.
Мы выяснили, что прямое подключение рабочей базы к хранилищу — это риск, который редко оправдан экономией времени. Для обеспечения стабильности бизнеса правильным решением будет внедрение процесса сборки релизов через промежуточные файлы конфигурации. Это позволяет полностью исключить влияние процесса разработки на текущую работу пользователей и гарантирует предсказуемость обновлений.