Новости и разборы
История деплоев: срок хранения должен совпадать с планом восстановления
Изменения Vercel и бета Artifact Central в GitLab: как связать хранение версий, доступность артефактов и ответственность команды.
Прошлая версия приложения полезна только пока её можно найти и применить. Когда платформа сокращает историю деплоев, это затрагивает план возврата к проверенному выпуску. Октябрьские объявления Vercel и GitLab показывают, почему хранение артефактов стоит обсуждать как часть эксплуатации, а не оставлять настройкой по умолчанию.
Что меняется у Vercel
В объявлении от 9 октября для существующих Pro-команд Vercel описывает оплату Deployment и Functions Storage и окно хранения в 30 дней. Старые деплои начнут удалять с 23 октября, если команда заранее не изменит настройку. Точная дата начала биллинга конкретной команды сообщается отдельно письмом.
Второе объявление той же даты относится к новым Pro-командам: 30 дней становятся значением по умолчанию. Удалённый деплой нельзя восстановить или использовать для rollback. Эти два сообщения адресованы разным группам; нельзя переносить один срок на все аккаунты без проверки их условий.
Для владельца приложения ближайший шаг конкретен: выяснить, какая политика действует в его проекте и какие проверенные версии останутся доступными после удаления. Не следует менять настройку вслепую только ради более короткой истории. Сначала определите, какой период нужен для обнаружения проблемы и кто принимает решение о возврате.
Реестр пакетов имеет свою политику
GitLab 6 октября представил Artifact Central в бесплатной бете: реестр на уровне организации с ролями, квотами и хранением, включая npm, Maven и Docker/OCI. Бета-статус нужно учитывать отдельно от требований к рабочему процессу.
Связь здесь не в взаимозаменяемости продуктов. Деплой и пакет могут храниться в разных местах и иметь разные сроки жизни. Если пакет исчез, наличие записи о выпуске ещё не означает возможность повторно развернуть тот же результат. И наоборот: сохранённый образ не объясняет, с какой конфигурацией и данными работала версия.
Проверка доступной истории
Составьте короткую карту: выпуск приложения, исходная ревизия, пакет или образ, параметры окружения и связанные изменения данных. Укажите место хранения и срок для каждого элемента. Не путайте резервную копию данных с историей приложения: они решают разные задачи.
На отдельном стенде попробуйте восстановить выбранную проверенную версию из действительно сохранённых материалов. Убедитесь, что путь не зависит от удалённого деплоя или случайного файла на ноутбуке. Зафиксируйте ответственного за политику и повторяйте проверку после её изменения.
Сервер как ядро процесса помогает отделить запуск от сохранения состояния. Архивный инфраструктурный материал описывает задачи восстановления без подтверждения текущей эксплуатации всех компонентов. Для вашего плана сопровождения обсудите доступную историю и проверку возврата версии.