обновление скриптов в д24

Автоматическое обновление и резервное копирование 1С при помощи powershell

Суть рассматриваемого вопроса изложена в заголовке, повествование разобьем на три части. Отдельно внизу будут приведены тексты скриптов.

1) Предисловие

Вопрос необходимости резервного копирования в автоматическом режиме не подлежит сомнению ни у корифеев, ни у новичков. В статье рассмотрим резервное копирование средствами 1С (что имеет ряд преимуществ перед копированием средствами СУБД). При этом будут применены средства пакетного запуска платформы 1С, powershell и планировщик задач Windows.

Задачи обновления информационных давно автоматизированы, но только для типовых конфигураций, либо тех, что используют библиотеку стандартных подсистем. В моем случае мы работаем со старенькой Альфа-Авто редакции 4, которая распространяется на 12 серверов. Изменения вносятся примерно два раза в неделю, поэтому выгода от автоматизации налицо.

В обоих случаях мы имеем следующие исходные данные:

2) Резервное копирование

После прочтения указанных ссылок мы уже знаем, что надо сделать, чтобы запустить скрипт powershell, поэтому сразу перейду к делу.

Сделать резервную копию информационной базы в пакетном режиме очень просто, надо только «выгнать» всех пользователей. Делать мы это будем, подключившись COM-объектом к базе данных. Это в нашем примере делает функция ExitAll. В тело функции зашито, что она вызывается на том сервере, на котором, собственно, установлен кластер серверов 1С. Вызовите эту функция безо всяких параметров в своем скрипте на сервере — и ВСЕ пользователи из ВСЕХ баз кластера вылетят.

Приношу свои извинения человеку, чьим кодом я воспользовался при написании этой процедуры — авторство восстановить не удалось.

После этого следует вызвать функцию BackUpBase с параметром — имя информационной базы. У меня во всех ИБ есть служебный администратор с одинаковыми учетными данными, поэтому я их просто захардкодил. При необходимости можно их параметризовать, либо обойтись аутентификацией ОС.

Итоговый скрипт сохраняем в файл.

В планировщике задач создаем «Простую задачу», имя, разумеется, на ваше усмотрение.
У меня работает ежедневно, но и тут хозяин — барин. Запускать лучше всего ночью, когда никто не работает, например, в 3:00. Действие для задачи — «Запустить программу». Сама программа у нас «powershell.exe». А вот ее аргументы —

где ExitAllUsersAndBackup.ps1 — как раз наш сохраненный скрипт.
-ExecutionPolicy RemoteSigned — ключ, который разрешает выполнение пакетных скриптов powershell, если в системе они глобально не разрешены. Работает через раз (возможно, не хватает компетенции чтобы разобраться, но закономерности не нашёл). В случаях, когда не работает с этим ключом, приходится разрешать выполнение скриптов для всего сервера.

Для этого Win+R, powershell.exe,

и подтверждаем действие.

Время работы с данными скриптами — более трех месяцев. Перебои были, но связаны с отключением электричества и прочими внешними факторами.

3) Обновление конфигурации

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

Конфигурацию мы храним на ftp-сервере, на который помещаем ее вручную. Файл конфигурации называется GK.cf, в приведенном примере обновляется одна единственная конфигурация. Потенциально можно так же обновлять и несколько различных конфигураций.
На ftp рядом с GK.cf помещаем файл с названием flag.txt. Наличие этого файла сигнализирует о том, что обновляться надо. Можно проверять наличие самого фйла GK.cf, но мы используем флаг так же для других целей.

Скрипт работает следующим образом:

Надежность этого скрипта чуть меньше. Обновление проходит до конца на 100% в тех случаях, когда меняется структура метаданных. В других случаях бывает, как я предупреждал ранее, появление активного пользователя. В результате конфигурация загружена в базу, но конфигурация базы данных не обновлена (снова прошу прощения за подобную кривоватую терминологию перед людьми, не связанными с 1С). В остальном — полет нормальный.

Скрипт резервного копирования

Скрипт обновления конфигурации

Благодарю за внимание. Готов к конструктивной критике.

Источник

PHP-скрипт, который обновляет сам себя

Задача: написать скрипт, который умеет загружать новую версию себя с удаленного сервера и самообновляться.

Практика автообновлений широко применяется среди десктоп-клиентов и операционных систем, но в вебе встречается редко. Однако, для скриптов, где одна установка обеспечивает работу одного ресурса (а это, фактически, все скрипты, которые ставишь себе на хостинг), автоматизированная возможность установки обновлений не менее важна, чем для десктопов. К веб-сервисам это, конечно, отношения не имеет.

Технически выполнить обновление скрипта не так уж и сложно — загрузить обновление с удаленного сервера и установить его поверх работающей версии — однако, есть некоторые нюансы. Мы в Вебасисте применяем практику установки удаленных обновлений уже давно и накопили большой опыт работы со всевозможными конфигурациями серверов хостинг-провайдеров. Поделимся опытом.

Это не туториал, поэтому вот сразу окончательный вариант скрипта: www.webasyst.com/etc/ru/selfupdate-1 (скрипт index.php; ≈20 КБ).
Скрипт содержит класс selfUpdate, который выполняет обновление самого себя (скачивает обновленную версию файла index.php и заменяет ей работающую в текущий момент).

Под катом рассмотрим как устроен процесс обновления и какие могут возникнуть проблемы при обновлении.

Как запустить скрипт?

Просто скачайте скрипт и загрузите в папку на сервере. Запустив скрипт в браузере, вы увидите заголовок Hello World и кнопки обновления скрипта.

Для того, чтобы обновление скрипта работало, нужно включить права на запись для корневой папки, куда установлен скрипт. Это необходимо, потому что скрипт будет создавать в этой папке поддиректорию для загрузки в нее обновленного скрипта с удаленного сервера. Если запускаете скрипт на локалхосте в Windows (например, на основе пакета «Денвер»), то права доступа предоставлять не надо — все будет работать само собой.

Скрипт index.php загружает с сервера свою обновленную версию как есть (не в архиве) и заменяет себя на нее. Обновление скриптов, в которых много файлов, в реальности отличается только тем, что с сервера загружается архив со скриптами. В остальном же все работает по такой же схеме: загрузил файлы — обновил файлы.

Загрузка файла с удаленного сервера

За обновлением скрипт идет по тому же адресу, который был представлен выше (http://www.webasyst.com/etc/ru/selfupdate-1/). Этот источник обновлений отдает «обновление» в виде вложения (для наглядности мы сделали две вариации: V1 выводит надпись Hello world, и V2 показывает сумму трех случайных чисел).

Загрузка файла с удаленного сервера из скрипта возможна двумя способами:

Через fopen(): Да, через обычный fopen(). Но для работы этой функции необходимо, чтобы в настройках PHP (php.ini) был установлен параметр allow_fopen_url = On и в списке поддерживаемых протоколов был HTTP.

Через cURL: Этот вариант предпочительнее, так как более гибкий. Например, при использовании cURL можно сделать возобновление загрузки в случае, если она была прервана.

Обновление работающего скрипта

Файл PHP-скрипта, работающего в текущий момент, не блокируется системой по записи, и поэтому его можно перезаписать. В связи с этим схема установки обновления в нашем примере следующая: файл загружается в отдельную подпапку (/updates/download/), проверяется правильно ли загрузился файл (соответствует ли размер скачанного файла размеру, заявленному в заголовках ответа, а также проверкой md5-хеша файла), и затем работающий скрипт index.php перезаписывается обновленным файлом.

В случае с одним файлом все тривиально: скачал и перезаписал. Интереснее, когда с сервера загружается архив со скриптами. Интереснее тем, что тут есть три варианта (стратегии) распаковки:
1) скачанный архив можно распаковывать поверх работающих скриптов: хороший вариант, но на момент распаковки это сломает работу системы, будет даунтайм;
2) скопировать текущую версию работающих скриптов во временную папку, распаковать поверх этой папки скачанный архив, рабочую версию переместить в директорию бекапов, а на её место обновленный код: вариант плох тем, что предполагает сохранение устаревших файлов;
3) распаковать архив в отдельную папку, а затем подменить работающую папку обновленной версией: этот вариант наиболее интересен, потому что предполагает наименьший даунтайм в работе скриптов.

Проблемы

Основные проблемы, возникающие при обновлении:

― max_input_time (ограничение на время операций ввода-вывода): скачивание файлов значительного объема может не уложиться в максимально допустимое время;
― max_execution_time: процесс обновления может упереться в ограничение на общее время работы скрипта. Особенность в том, что такого не может случиться при загрузке файла с удаленного сервера, т.к. PHP не считает время на операции с файлами (хотя, есть особенности в Windows-системах), однако, ограничение становится критичным при распаковке архивов значительных размеров;
― доступность сервера обновлений: помимо отсутствия подходящего транспорта для загрузки обновления (посредством fopen или curl) могут иметь место проблемы с сетью (DNS, роутинг, firewall);
― разрывы соединения с сервером во время скачивания файла: необходимо проверять целостность файла после загрузки, но для этого сервер, который выдает обновление, должен уметь отдавать и md5-хеши файлов.

Перечисленные проблемы характерны для загрузки больших архивов. Для обновления одного двадцатикилобайтного index.php это не актуальны (за исключением необходимости проверить целостность загруженного файл).

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

Источник

Автоматическое обновление скриптов после деплоя

Пролог

Добрый день, уважаемые читатели. Эта статья посвящена проблеме, с которой сталкиваются разработчики более-менее серьезных веб-сайтов, а именно – проблеме автоматического обновления скриптов в браузере пользователя после деплоя.

Суть проблемы заключается в том, что одностраничное приложение, загруженное в браузере пользователя, не знает о том, что скрипты были только что изменены, и, следовательно, необходимо обновиться. С точки зрения пользователя это выглядит как непонятные ошибки, возникающие на ровном месте, или как отказ приложения выполнять свои функции. Все это – следствие того, что версия скриптов на сервере изменилась, и приложение просто не может их найти и загрузить.

Конечно, все решается нажатием на F5, но в данной статье я покажу, как можно автоматизировать это действие, избавить пользователя от головной боли и сделать это красиво.

О статье

Данная статья представляет из себя туториал и предназначена как для опытных разработчиков, так и для новичков.

Решение, представленное здесь, разработано для VueJS версии 2.6.x, но сами алгоритмы легко могут быть портированы на любой js-фреймворк на основе webpack’а.

Статья имеет веб-интерфейс, где вы сможете пощупать решение своими руками, а также исходники на github.

Ссылки для ленивых:
Веб-интерфейс: http://vue-auto-reload.doomer3d.ru/
Проект на github: https://github.com/Doomer3D/vue-auto-reload

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

Идея решения

Идея решения заключается в введении версионности веб-приложения на уровне сборки.

Каждый раз при сборке мы сохраняем информацию о времени сборки, а во время работы приложения проверяем, изменилось ли это время. В случае изменения, обновляем страницу, попутно предупреждая пользователя об изменениях.

Реализация

Решение представлено в виде плагина для Vue, который находится в коде проекта по пути /src/plugins/AutoReload. Отдельного пакета для npm не делал.

Демонстрационное веб-приложение представляет коробочную заготовку vue-cli, в которую добавлены стандартные фичи: store, роутер, axios для веб-запросов и dayjs для работы с датами. Интерфейс построен на Element

Версионность сборки

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

Итак, рассмотрим последний вариант в контексте VueJS и Webpack. Как известно, сборщик webpack выполняет серверные js-скрипты, которые собственно и выполняют сборку. В них мы можем встроить свой код, который будет формировать специальный файл, скажем version.json, который будет содержать полезную для нас информацию.

В контексте нашей задачи достаточно записать туда дату сборки, но мы пойдем чуть дальше и добавим информацию о типе сборки (development/production/etc.) и версию проекта из файла package.json. Получим примерно такой файл:

Чтобы сформировать данный файл, нужно встроить код в скрипт vue.config.js, вот так:

Далее код самого генератора version.json:

Теперь каждый раз при сборке приложения через команды serve, build или другие будет формироваться новая версия файла version.json, которая может быть прочитана приложением через обычный get-запрос, что нам и требуется.

Примечание №1. Файл version.json помещается в папку public, содержимое которой в VueJS копируется в выходной каталог «как есть». В других фреймворках может потребоваться другое целевое расположение.

Примечание №2. Файл version.json нужно исключить из git’а, чтобы его изменение не вызывало конфликтов при командной разработке, ведь изменяться он будет постоянно даже в процессе отладки.

Плагин AutoReload

Исходя из идеи решения плагин будет выполнять следующие функции:

Конфигурация плагина

Любой уважающий себя плагин должен иметь возможности для настройки. Наш плагин не является исключением, хотя его настройки ограничены рамками задачи, для которой он разрабатывался:

Код файла конфигурации можно найти в исходниках или под спойлером.

Использование плагина

Данный плагин имеет одну особенность, – он использует роутер и уведомления Element’а, поэтому его нужно включать в методе create главного компонента Vue:

Разбор кода плагина

Главной функцией является check с опциональным параметром href. Именно эта функция вызывается по таймеру или при переходе по маршруту, в этом случае передается адрес целевой страницы.

Функция получает текущую версию сборки из файла version.json и сравнивает дату сборки с ранее сохраненным значением.
Если значение отличается, пользователю показывается уведомление, затем сохраняется новое значение версии сборки и происходит перезагрузка страницы.

Если обновление происходит по таймеру, эмулируется нажатие F5 (window.location.reload(true)). Если же обновление происходит при переходе по маршруту, пользователь направляется на целевую страницу маршрута. Это важно, т.к. исполнение кода никогда не дойдет до next() в хуке роутера после обновления страницы.

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

Бонус №1. Использование информации о версии сборки в целях отладки

Я не случайно добавил в файл version.json дополнительную информацию о версии проекта и типе сборки. В реальном проекте эта информация выводилась на специальной «скрытой» странице, в которую можно было попасть, указав ее путь в URL. В демонстрационном проекте страничка с информацией о сборке находится прямо в меню, и там можно увидеть содержимое файла version.json в удобном для человека виде.

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

Также туда можно добавить информацию о бэкенде, но в этом проекте его нет.

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

Исходное решение было написано на C# много лет назад, а затем портировано на JS почти в неизменном виде. Я приведу код обоих решений и примеры использования.

Исходник на C#: https://pastebin.com/T1PsMy4N

Исходник на JS: https://pastebin.com/a4z25b1H

Анализ решения

У любого решения есть плюсы и минусы, а также свои особенности и, конечно, простор для дальнейших доработок. Здесь проведу краткий анализ своего решения в плане его ограничений и доработок.

Проблема распределенного приложения

Если приложение работает через балансер, и сборка происходит на каждом из веб-серверов отдельно, то, очевидно, версия сборок будет отличаться минутами или секундами. Поэтому, если пользователь по какой-то причине будет перекинут на другой веб-сервер, у него произойдет обновление скриптов из-за различий во времени сборки.

Является ли это проблемой? Скорее нет, чем да, потому что балансер, как правило, настроен таким образом, чтобы пользователь всегда направлялся на один из вебов, а не прыгал между ними.

Если все-таки такая проблема актуальна для вас, я вижу два варианта решения: сборка на одном сервере или введение проверки на разность дат сборок, чтобы она превышала некий лимит.

Проблема асинхронных компонентов

В плагине решена проблема подгрузки асинхронных маршрутов, но остается нерешенной проблема, когда пользователь производит действие, вызывающее подгрузку асинхронного компонента. С точки зрения браузера это загрузка обычного js-файла с сервера. Но после деплоя и до срабатывания автоматического обновления браузер будет пытаться загрузить несуществующий файл.

У данной проблемы нет нормального решения, хотя есть вариант с перехватом/оборачиванием кода подтягивания асинхронных компонентов, чтобы в этот момент также вызывался код проверки изменения версии сборки. В любом случае, максимум, что возможно будет сделать – перезагрузить страницу целиком.

Проблема потери данных

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

Как вариант, можно не инициировать обновление страницы, а давать пользователю выбор: продолжить работу или обновить страницу.

Проблема публикации списка изменений

Честно говоря, не припомню сайты, которые публикуют какие-либо changelog’и, но было бы интересно внедрить такой функционал в модуль автообновления. Хотя лично меня всегда бесит, когда тот же телеграм пишет мне в личку список новых возможностей. Каждый раз я удаляю тот чат, но он все равно оживает при следующем обновлении. А для веба это, наверное, и не нужно вовсе.

Плагин в действии

Если вы хотите увидеть плагин в действии, воспользуйтесь демонстрационным стендом.

Нажмите на кнопку, которая сбрасывает сохраненную в плагине версию, что приведет к срабатыванию автоматического обновления после истечения минутного таймера или при переходе в другой раздел меню.

Заключение

Надеюсь, что данная статья поможет вам решить проблему с автоматическим обновлением скриптом или хотя бы даст направление исследования. Также прошу оценить, насколько вам зашли «бонусы», и стоит ли их использовать в дальнейшем?

Понравилась статья? Посмотрите другие:

Источник

Автоматическое обновление скриптов после деплоя

Добрый день, уважаемые читатели. Эта статья посвящена проблеме, с которой сталкиваются разработчики более-менее серьезных веб-сайтов, а именно – проблеме автоматического обновления скриптов в браузере пользователя после деплоя.

Суть проблемы заключается в том, что одностраничное приложение, загруженное в браузере пользователя, не знает о том, что скрипты были только что изменены, и, следовательно, необходимо обновиться. С точки зрения пользователя это выглядит как непонятные ошибки, возникающие на ровном месте, или как отказ приложения выполнять свои функции. Все это – следствие того, что версия скриптов на сервере изменилась, и приложение просто не может их найти и загрузить.

Конечно, все решается нажатием на F5, но в данной статье я покажу, как можно автоматизировать это действие, избавить пользователя от головной боли и сделать это красиво.

О статье

Данная статья представляет из себя туториал и предназначена как для опытных разработчиков, так и для новичков.

Решение, представленное здесь, разработано для VueJS версии 2.6.x, но сами алгоритмы легко могут быть портированы на любой js-фреймворк на основе webpack’а.

Статья имеет веб-интерфейс, где вы сможете пощупать решение своими руками, а также исходники на github.

Ссылки для ленивых:

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

Идея решения

Идея решения заключается в введении версионности веб-приложения на уровне сборки.

Каждый раз при сборке мы сохраняем информацию о времени сборки, а во время работы приложения проверяем, изменилось ли это время. В случае изменения, обновляем страницу, попутно предупреждая пользователя об изменениях.

Реализация

Решение представлено в виде плагина для Vue, который находится в коде проекта по пути /src/plugins/AutoReload. Отдельного пакета для npm не делал.

Демонстрационное веб-приложение представляет коробочную заготовку vue-cli, в которую добавлены стандартные фичи: store, роутер, axios для веб-запросов и dayjs для работы с датами. Интерфейс построен на Element.

Версионность сборки

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

Итак, рассмотрим последний вариант в контексте VueJS и Webpack. Как известно, сборщик webpack выполняет серверные js-скрипты, которые собственно и выполняют сборку. В них мы можем встроить свой код, который будет формировать специальный файл, скажем version.json, который будет содержать полезную для нас информацию.

В контексте нашей задачи достаточно записать туда дату сборки, но мы пойдем чуть дальше и добавим информацию о типе сборки (development/production/etc.) и версию проекта из файла package.json. Получим примерно такой файл:

Чтобы сформировать данный файл, нужно встроить код в скрипт vue.config.js, вот так:

Далее код самого генератора version.json:

Теперь каждый раз при сборке приложения через команды serve, build или другие будет формироваться новая версия файла version.json, которая может быть прочитана приложением через обычный get-запрос, что нам и требуется.

Примечание №1. Файл version.json помещается в папку public, содержимое которой в VueJS копируется в выходной каталог «как есть». В других фреймворках может потребоваться другое целевое расположение.

Примечание №2. Файл version.json нужно исключить из git’а, чтобы его изменение не вызывало конфликтов при командной разработке, ведь изменяться он будет постоянно даже в процессе отладки.

Плагин AutoReload

Исходя из идеи решения плагин будет выполнять следующие функции:

Конфигурация плагина

Любой уважающий себя плагин должен иметь возможности для настройки. Наш плагин не является исключением, хотя его настройки ограничены рамками задачи, для которой он разрабатывался:

Код файла конфигурации можно найти в исходниках или под спойлером.

Использование плагина

Данный плагин имеет одну особенность, – он использует роутер и уведомления Element’а, поэтому его нужно включать в методе create главного компонента Vue:

Разбор кода плагина

Главной функцией является check с опциональным параметром href. Именно эта функция вызывается по таймеру или при переходе по маршруту, в этом случае передается адрес целевой страницы.

Функция получает текущую версию сборки из файла version.json и сравнивает дату сборки с ранее сохраненным значением. Если значение отличается, пользователю показывается уведомление, затем сохраняется новое значение версии сборки и происходит перезагрузка страницы.

Если обновление происходит по таймеру, эмулируется нажатие F5 (window.location.reload(true)). Если же обновление происходит при переходе по маршруту, пользователь направляется на целевую страницу маршрута. Это важно, т.к. исполнение кода никогда не дойдет до next() в хуке роутера после обновления страницы.

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

Бонус №1. Использование информации о версии сборки в целях отладки

Я не случайно добавил в файл version.json дополнительную информацию о версии проекта и типе сборки. В реальном проекте эта информация выводилась на специальной «скрытой» странице, в которую можно было попасть, указав ее путь в URL. В демонстрационном проекте страничка с информацией о сборке находится прямо в меню, и там можно увидеть содержимое файла version.json в удобном для человека виде.

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

Также туда можно добавить информацию о бэкенде, но в этом проекте его нет.

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

Исходное решение было написано на C# много лет назад, а затем портировано на JS почти в неизменном виде. Я приведу код обоих решений и примеры использования.

Анализ решения

У любого решения есть плюсы и минусы, а также свои особенности и, конечно, простор для дальнейших доработок. Здесь проведу краткий анализ своего решения в плане его ограничений и доработок.

Проблема распределенного приложения

Если приложение работает через балансер, и сборка происходит на каждом из веб-серверов отдельно, то, очевидно, версия сборок будет отличаться минутами или секундами. Поэтому, если пользователь по какой-то причине будет перекинут на другой веб-сервер, у него произойдет обновление скриптов из-за различий во времени сборки.

Является ли это проблемой? Скорее нет, чем да, потому что балансер, как правило, настроен таким образом, чтобы пользователь всегда направлялся на один из вебов, а не прыгал между ними.

Если все-таки такая проблема актуальна для вас, я вижу два варианта решения: сборка на одном сервере или введение проверки на разность дат сборок, чтобы она превышала некий лимит.

Проблема асинхронных компонентов

В плагине решена проблема подгрузки асинхронных маршрутов, но остается нерешенной проблема, когда пользователь производит действие, вызывающее подгрузку асинхронного компонента. С точки зрения браузера это загрузка обычного js-файла с сервера. Но после деплоя и до срабатывания автоматического обновления браузер будет пытаться загрузить несуществующий файл.

У данной проблемы нет нормального решения, хотя есть вариант с перехватом/оборачиванием кода подтягивания асинхронных компонентов, чтобы в этот момент также вызывался код проверки изменения версии сборки. В любом случае, максимум, что возможно будет сделать – перезагрузить страницу целиком.

Проблема потери данных

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

Как вариант, можно не инициировать обновление страницы, а давать пользователю выбор: продолжить работу или обновить страницу.

Проблема публикации списка изменений

Честно говоря, не припомню сайты, которые публикуют какие-либо changelog’и, но было бы интересно внедрить такой функционал в модуль автообновления. Хотя лично меня всегда бесит, когда тот же телеграм пишет мне в личку список новых возможностей. Каждый раз я удаляю тот чат, но он все равно оживает при следующем обновлении. А для веба это, наверное, и не нужно вовсе.

Плагин в действии

Если вы хотите увидеть плагин в действии, воспользуйтесь демонстрационным стендом.

Нажмите на кнопку, которая сбрасывает сохраненную в плагине версию, что приведет к срабатыванию автоматического обновления после истечения минутного таймера или при переходе в другой раздел меню.

Заключение

Надеюсь, что данная статья поможет вам решить проблему с автоматическим обновлением скриптом или хотя бы даст направление исследования. Также прошу оценить, насколько вам зашли «бонусы», и стоит ли их использовать в дальнейшем?

Источник