Comments 8
Честно говоря, не уверен, что действительно стоит обновлять страницу сразу после деплоя: как минимум это плохо тем, что это вызовет шквал запросов от пользователя сразу после деплоя. Если деплой происходит часто, то это будет ещё и плохой user experience.
Также нужно учитывать, что у многих (большинства?) более-менее крупных сервисов есть ещё и мобильные клиенты, а иногда и десктопные тоже, и соответственно у вас должен быть более-менее стабильный API на стороне бэкенда, и соответственно, если вы из JS обращаетесь напрямую к этому API, то не обязательно перезагружать страницу пользователя принудительно. Понятно, что часто для веба делают ещё один слой между чистым API на бекенде и фронтендом, но даже в этом случае иметь некоторую обратную совместимость было бы тоже полезно.
на backend хранится версия. с фронта все запросы происходят с хедером 'HTTP_X_CLIENT_VERSION' = версия у клиента.
на backend смотрим версию в хедере запроса и если не совпадает с текущей — возвращаем код 418 с текущей версией. на фронте сохраняется версия из ответа и обновляется страница.
лучше не придумал пока
Лучше использовать не дату сборки как идентификатор версии, а contenthash — хэш-строку на основе анализа содержимого файла, либо commithash — хэш последнего коммита. Это поможет избежать лишних срабатываний (при использовании балансера или пересборок).
Также рекомендую включать комментарий в каждый из итоговых js и css файлов с версией, пример для Webpack:
/**
* @docs: https://webpack.js.org/plugins/banner-plugin
*
*/
import webpack from 'webpack';
import pkg from '../../package.json';
import { env } from '../../env';
export const pluginBanner: webpack.WebpackPluginInstance = new webpack.BannerPlugin({
banner: `@env ${env.NODE_ENV}:${pkg.version} @commit ${env.GIT_COMMIT}`,
entryOnly: false,
});
Это позволит осуществлять дебаг без открытия доп. файла, узнавать у клиентов версии загруженных ресурсов (для решения проблем с кэшем, особенно актуально при использовании Service Worker), решить проблему с асинхронной загрузкой чанков (в случае, если их имена не модифицируются — можно в script.onload проверять совпадение версии в комментарии чанка и версии основного файла).
По поводу потери данных — можно определить интерактивные части (формы) и при обновлении версии фронтенда стор сохранять в Local Storage и восстанавливать после перезагрузки. Если меняется формат данных в сторе — то соответственно нужна схема миграции. Если компания нацелена на создание качественного продукта, это все несложно внедрить.
Да, и если есть SSR, то посылать информацию об обновлении файлов можно по сокету с ноды, а не методом опроса раз в минуту — выглядеть будет приятней, лишние запросы уйдут.
Автоматическое обновление скриптов после деплоя