Как реализовать пакетное обновление клиент-серверных баз 1С из хранилища с завершением сеансов?

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

Использование штатных параметров командной строки 1С

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

Нам понадобятся следующие параметры командной строки:

• /ConfigurationRepositoryF — путь к хранилищу конфигурации (каталог или адрес сервера).
• /ConfigurationRepositoryN — имя пользователя в хранилище.
• /ConfigurationRepositoryP — пароль пользователя в хранилище.
• /ConfigurationRepositoryUpdateCF — ключевая команда, которая дает указание платформе обновить основную конфигурацию базы данными из хранилища.
• /UpdateDBCfg — команда для обновления конфигурации базы данных (применение изменений к структуре SQL-таблиц).
• /UC — код разрешения доступа, который позволит нам войти в базу, когда она заблокирована для остальных пользователей.

Пример командной строки для выполнения этой операции может выглядеть следующим образом:

"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /S "ServerName\BaseName" /N "Admin" /P "AdminPassword" /ConfigurationRepositoryF "tcp://RepoServer/MainRepo" /ConfigurationRepositoryN "RepoUser" /ConfigurationRepositoryP "RepoPass" /ConfigurationRepositoryUpdateCF /UpdateDBCfg /UC "КодДоступа"

Принудительное завершение сеансов и блокировка базы

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

Наиболее современным и рекомендуемым способом является использование утилиты RAC (Remote Administration Client), которая поставляется вместе с сервером 1С. Рассмотрим алгоритм действий:

1. Установка блокировки соединений: Мы должны запретить новые подключения. С помощью rac устанавливается признак блокировки и задается КодРазрешения.
2. Отключение существующих сеансов: Через ту же утилиту мы получаем список всех ID сеансов и поочередно отправляем команду на их завершение.
3. Блокировка регламентных заданий: Крайне важно также установить параметр ScheduledJobsDenied = True, чтобы фоновые процессы не пытались стартовать в момент реструктуризации таблиц.

Пример команды для блокировки соединений через rac:

rac infobase --cluster=<ID_Кластера> update --infobase=<ID_Базы> --sessions-denied=on --scheduled-jobs-denied=on --permission-code=MySecretCode --denied-from="2023-10-27T20:00:00"

Автоматизация через OneScript и пакет TRun1C

Если написание сложных .bat файлов кажется избыточным, разберем использование специализированных инструментов. Посмотрим на библиотеку TRun1C для OneScript. OneScript позволяет писать скрипты автоматизации на привычном языке 1С, что значительно упрощает поддержку кода.

С помощью TRun1C можно описать процесс обновления объектно-ориентированным способом. Проанализируем примерную логику скрипта:

// Инициализация параметров запуска
ПараметрыЗапуска = Новый ПараметрыЗапускаКонфигуратора;
ПараметрыЗапуска.СтрокаСоединения = "Srvr='Server';Ref='Base';";
ПараметрыЗапуска.Пользователь = "Admin";
ПараметрыЗапуска.Пароль = "Pass";

// Настройка работы с хранилищем
ПараметрыЗапуска.ХранилищеПуть = "tcp://Server/Repo";
ПараметрыЗапуска.ХранилищеПользователь = "RepoUser";
ПараметрыЗапуска.ХранилищеПароль = "RepoPass";

// Выполнение обновления
Результат = ЗапуститьОбновлениеИзХранилища(ПараметрыЗапуска);
Если Результат = 0 Тогда
    Сообщить("Обновление успешно завершено");
КонецЕсли;

Преимущество этого подхода в том, что библиотеки типа v8runner или Deployka (также на базе OneScript) уже содержат внутри себя встроенные механизмы ожидания завершения сеансов и обработки ошибок платформы.

Использование «Обновлятора-1С» (Милькина)

Рассмотрим еще одно популярное решение, упомянутое в обсуждении — «Обновлятор-1С». Это готовое приложение, которое берет на себя всю рутину. Выясним, почему оно эффективно для работы с хранилищем:

• Автоматический выгон пользователей: Программа сама подключается через COM или RAC и завершает работу пользователей перед началом процесса.
• Интеграция с хранилищем: В настройках задачи обновления можно указать параметры хранилища, и программа сама выполнит цепочку команд /ConfigurationRepositoryUpdateCF и /UpdateDBCfg.
• Контроль результата: Если при обновлении структуры базы данных произойдет ошибка, «Обновлятор» отправит уведомление (например, в Telegram или на почту) и не будет пытаться запустить базу в битом состоянии.
• Бекапирование: Перед получением изменений из хранилища можно настроить создание автоматической резервной копии средствами SQL или средствами 1С.

Критически важные рекомендации при пакетном обновлении

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

1. Отказ от динамического обновления. В автоматических скриптах никогда не используйте ключ -Dynamic. Динамическое обновление часто приводит к рассинхронизации кэша на клиентских машинах и сервере приложений 1С. Только полное обновление с предварительной очисткой сеансов гарантирует стабильную работу.

2. Использование кодов разрешения (UC). Всегда прописывайте параметр /UC. Если ваш скрипт блокирует базу, но сам запускается без этого кода, он не сможет зайти в конфигуратор для выполнения обновления.

3. Проверка кодов возврата. После выполнения каждой команды платформы (будь то выгрузка или обновление) обязательно анализируйте системную переменную %ERRORLEVEL% (в Windows). Значение 0 означает успех, любое другое — ошибку. Это позволит вовремя остановить конвейер обновления и не допустить повреждения данных.

4. Очистка серверного кэша. В некоторых случаях после массового обновления из хранилища полезно добавить в скрипт команду перезапуска службы 1C:Enterprise Server Administration и очистку папки snccntx, чтобы исключить странное поведение метаданных у пользователей.

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