Что делают эти скрипты, если кратко?
Скрипт по копированию базы данных CopyBase.os
Вам звонят и сообщают, что в заказе номер 667 ошибка и надо бы поправить. А в вашей базе нет этого заказа. Не набивать же его вручную? Запускаете скрипт Import.bat, ждете 2-30 минут, и вот уже в вашей базе самая свежая копия рабочей, уже подключена к хранилищу разработки и обновлена.
Скрипт по деплою Deploy.os
Настала пора обновить рабочую базу. Вы заранее положили все нужно в хранилище рабочей базы.
В час X вы начинаете обновление: оповещаете пользователей о том, что надо бы из 1Ски всем выйти (никто конечно не выходит),
начинаете рубить соединения вручную (фоновые задания и самые упертые возвращаются быстрее, чем вы их успеваете удалить),
ставите блокировку на базу (и сами долго мучаетесь с заходом в конфигуратор. Доходит до того, что вы снимаете блокировку, забегаете в конфигуратор и снова ставите блокировку, надеясь, что именно сеанс конфигуратора не умрет. Он умирает),
делаете бекап (он длится что то долго и вы отвлекаетесь на пару статей. Когда возвращаетесь в базе уже тусуются пользователи, а бекап уже морально устарел),
обновляете (ребутнув сервер пару раз, т.к. пользователи так и не перестали заходить),
с чистой совестью идете гулять с семьей/пить пиво с друзьями (вам звонят и говорят, что не могут зайти в базу. Видимо кто то забыл выполнить миграцию).
Скрипт же делает все то же самое, но быстрее и надежнее. Он ставит мягкую блокировку (когда новые пользователи не могут зайти, а старым выскакивает сообщение с предложением сохраниться и завершить работу), потом отрубает все соединения принудительно, выполняет бекап, обновляется из хранилища, обновляет базу данных, запускает миграцию данных и снимает блокировку, когда все завершено.
Как работают скрипты, если подробнее
Сами скрипты написаны на oscript. На инфостарте этот проект уже известен, поэтому не буду сильно его хвалить.
Через батник запускается на выполнение оскрипт, ему передается скрипт и параметры к нему.
Особым образом читаются все необходимые параметры (об этом чуть ниже).
CopyBase.os
Шаг Выполнить бекап.
Выполняет бекап базы источника средствами SQLCMD (в моем примере это рабочая база).
Может быть пропущен, если параметр "Source_SQL.UseBackup" = false .
Выполняет бекап в файл "FileBackup" для SQL базы-источника с параметрами "Source_SQL.Server", "Source_SQL.User", "Source_SQL.Password", "Source_SQL.Base"
Если бекап выполнить не удалось- скрипт завершает работу аварийно.
Шаг Проверить соединения
Проверяет, что в базе-приемника (в моем примере это наша база разработки, в которую мы разворачиваем копию) нет соединений.
Пропускается, если "SQL.UseRestore" = false
Получает количество соединений для SQL базы-приемника с параметрами "SQL.Server", "SQL.User", "SQL.Password", "SQL.Base"
Если получить соединения не удалось или соединений больше 0 - скрипт завершает работу аварийно.
Шаг Выполнить восстановление
Запускает скрипт "Script_Restore" для базы "SQL.Server", "SQL.User", "SQL.Password", "SQL.Base"
Может быть пропущен, если "SQL.UseRestore" = false
Обойтись без отдельного скрипта не получилось, и проще всего восстановления было сделать через sql-скрипт. Этот скрипт можно получить при интерактивной попытке восстановить бекап в нужную базу (указав пути к файлам, расставив нужные флажки и быть может указав дополнительные действия). Скрипт должен восстанавливать именно ту базу, для который запущен оскрипт и именно из файла "FileBackup"
Шаг Удалить файл бекапа
Удаляет файл "FileBackup". Может быть пропущен, если "SQL.UseRestore" = false или "SQL.DelBackup" = false
Шаг Переподключить хранилище
Может быть пропущен, если "Repo.Blind" = false.
Подключается к базе-приемнику с параметрами "EXE1CV8", "Base.Connect", "Base.User", "Base.Password"
Отключает базу от хранилища (на случай, если она подключена к другому хранилищу), подключается к хранилищу с параметрами "Repo.Connect", "Repo.User" и "Repo.Password"
Если "UpdateCfg"=true, то выполняет обновление БД
Deploy.os
Шаг Включить RAS
Может быть пропущен, если "Cluster.UseLock" = false, "UseDynamicUpdate" = false или не заполнен "EXERAS".
Выполняет запуск RAS. Есть смысл, если скрипт выполняется на том же сервере, что и сервер 1С.
Именно с помощью RAS и RAC происходит взаимодействие с кластером, с помощью которого устанавливается блокировка и выполняется принудительное завершение работы у пользователей.
Шаг Устанавить блокировку
Может быть пропущен, если "Cluster.UseLock" = false, "UseDynamicUpdate" = false
Для установки блокировки используется куча параметров:
- "Cluster.ras" - сетевой адрес к RAS, например localhost
- "EXERAC" - путь к RAC
- "Base.Base" - имя базы в кластере
- "Cluster.Admin"
- "Cluster.Password"
- "v8version" - используемая версия 1Ски
- "Cluster.lockuccode" - код блокировки
- "Cluster.lockmessage" - сообщение о блокировке
- "Cluster.lockstart" - дата и время начала блокировки
- "Cluster.lockstartat" - количество секунд, через которое нужно установить блокировку
Шаг Пауза перед удалением сеансов
Может быть пропущен, если "Cluster.UseLock" = false, "UseDynamicUpdate" = false
Скрипт останавливается на время до окончательной блокировки, которое задается параметрами "Cluster.lockstart" или "Cluster.lockstartat"
Шаг Удалить соединения
Может быть пропущен, если "Cluster.UseLock" = false, "UseDynamicUpdate" = false
Удаляет все соединения.
Шаг Выполнить бекап
Пропустить нельзя
Выполняет бекап в файл "FileBackup" для SQL базы-приемника с параметрами "SQL.Server", "SQL.User", "SQL.Password", "SQL.Base". В отличие от выполнения аналогичного шага в скрипте CopyBase.os тут выполняется бекап именно для текущей базы, а не для базы-источника.
Шаг Обновить конфигурацию из хранилища
Можно пропустить, если "UpdateCfg"=false
Подключается к базе-приемнику с параметрами "EXE1CV8", "Base.Connect", "Base.User", "Base.Password"
Подключается к хранилищу с параметрами "Repo.Connect", "Repo.User" и "Repo.Password", получает из него все обновления и выполняет обновление БД. Если указан флаг "UseDynamicUpdate" = true то обновление динамическое.
Шаг Запуск миграции
Можно пропустить, если "UpdateCfg"=false
Запускает 1С с параметром запуска указанным в "UpdateLaunchParameter". Подразумевается, что в самой базе уже есть код, который по этому параметру запуска полностью автоматически выполнит обновление. Для баз на основе БСП уже все есть и этот ключ "ВыполнитьОбновлениеИЗавершитьРаботу", но это не точно.
Шаг Снять блокировку
Может быть пропущен, если "Cluster.UseLock" = false, "UseDynamicUpdate" = false
Снимает блокировку и разрешает вход пользователям.
Указание параметров и файлы настроек
Пример файлов с настройками лежит в папке bin.
Параметры читаются за счет библиотеки https://github.com/Stepa86/ReadParams
Параметры хранятся в json файлах. Они удобны для чтения и редактирования без использования спец. инструментов. Главное не забывать заменять \ на \\
Особенности указания параметров в строке запуска
Файл параметров по умолчанию
В первую очередь читается файл param_os.json, его не нужно указывать в строке запуска. Таким образом строка запуска
oscript ..\..\..\src\deploy.os
Прочитает файлы из файла param_os.json и нормально отработает.
Переданный файл параметров
Файл с параметрами можно указать явно, причем файлов может быть несколько - они должны быть разделены ;. Каждый последующий файл может переопределить параметры предыдущего.
oscript ..\..\..\src\deploy.os -debug -testparam "..\param\exe1c.json";"..\param\cluster.json";"..\param\sql.json";base.json;Dynamic.json
Особенности чтения файлов параметров
При разработке я придерживался правила - один параметр указывается один и только один раз. Когда обновляется 1Ска на сервере - нужно изменить только один параметр, а не 15 файлов.
Для этого при чтении параметров работает механизм подстановки
{
"v8version": "8.3.10.2168",
"EXE1CV8": "c:\\program Files (x86)\\1cv8\\%v8version%\\bin\\1cv8.exe",
"EXERAC": "C:\\Program Files\\1cv8\\%v8version%\\bin\\rac.exe",
// Если RAS уже запущен, то этот параметр следует удалить. Используется для старта RAS принудительно
"EXERAS": "C:\\Program Files\\1cv8\\%v8version%\\bin\\ras.exe"
}
и в качестве параметра можно указать другой файл для чтения. Вот пример файла param_os.json, который подтянет все остальные параметры из других файлов
{
"ReadFile.exe1c": "..\\param\\exe1c.json",
"ReadFile.cluster": "..\\param\\cluster.json",
"ReadFile.sql": "..\\param\\sql.json",
"ReadFile.Base": ".\\base.json"
}
Флаги запуска
Можно перед указанием файлов указать флаги -debug и -testparam . Что они делают описано выше.
Рекомендуемое расположение файлов параметров
[bin] // Папка в проекте
[Server] // Папка, в которой лежат все параметры для одного этого сервера
[param] // Папка с общими параметрами, применимыми для этого сервера
cluster.json // Общие параметры кластера для Server
exe1c.json // Общие параметры с путями к exe
import.json // Общие параметры для импорта скриптом CopyBase
sql.json // Общие параметры текущего SQL, который использует текущий Server
[DB1] // Папка с параметрами, применимыми для этой базы
deploy.bat // Батник для деплоя
import.bat // Батник для CopyBase
testparam.bat // Батник для тестов параметров
base.json // Параметры этой базы
import.json // Параметры базы, из которой нужно импортировать
param_os.json // Файл с ссылкой на другие файлы параметров
Restore_BaseName_PC.sql // SQL скрипт для восстановления в текущую базу из базы-источника
Исходный код и всегда самая свежая версия доступна на гитхабе https://github.com/Stepa86/1C-Deploy-and-CopyDB
