Выполняется тестирование параметров - что к хранилищу коннектится, что кластер отвечает и что доступ к SQL получен. Если передать параметр -testparam, то на этом скрипт будет остановлен. Нужно это для проверки всех важных параметров до того, как начались длительные или безвозвратные операции, а то очень обидно, когда уже и пользователи изгнаны и бекап выполнен, а пароль к хранилищу не подошел.

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